내가 일했던 한 SaaS 회사에서는, 사용자들이 실제로 사용하는 기능의 일부만을 기준으로 분석을 시도했던 적이 있음. 몇 가지 핵심 사용자 유형에 맞춰 제품 복잡성을 줄이고, 성가신 기능도 없애고자 했음. 결과적으로 로그인 화면을 제외하면, 모두 각자 중요하게 생각하는 20%가 전혀 달랐음. 분석 결과는 가중치를 둔 무작위 추출과 다를 바가 없었음
정말 공감함. 그런데 엔터프라이즈 고객에게 제품을 판매하기 시작하면 상황이 완전히 바뀜. "위생적 기능" 하나 부족하면 거래가 무산될 수 있음. 그리고 각 엔터프라이즈마다 꼭 필요한 기능이 다 다름. 위생적 기능은 화장실처럼 누구나 필요로 하는 최소 필수 요소를 비유함
지금까지 같은 제품을 두 번 팔아본 적이 없다는 느낌임. 제품 로드맵은 내가 마지막으로 누구와 대화했는지에 따라 정해짐. 고객이 없으면 안 된다고 강조했던 5,000개의 '필수' 기능을 거의 프로덕션 수준으로 유지하는 기술부채로 고생하고 있음. 하지만 실제론 고객이 거의 사용하지 않음
Joel Spolsky의 글들이 세월이 흘러도 정말 유효하다는 것에 놀라움을 느낌. 일부는 후에 틀린 것으로 드러나기도 했지만(그래픽 카드가 얇은 마진의 사업이 될 거라고 예측했던 것 등 참고), 대부분은 지금도 진리임. 심지어 당시보다 더 설득력이 있을 수 있음
두 번째(단순성) 글과 정말 비슷함. 저자가 이런 고전 포스트를 몰랐을 수도 있음. 요즘 세대는 그런 고전을 잘 안 읽는 것 같음. 참고로 Joel Spolsky, Steve McConnell, Don Norman 등 여러 명이 개발 직업에 대해 깊이 고민하고 그 생각을 기록해둠. 한 번쯤 읽어볼 만함
개인적인 취미 앱을 직접 만들어 봤는데, 종종 다듬어서 공개해보고 싶다고 생각함. 하지만 내 앱을 홍보하거나 알릴 의지가 전혀 없어서 공개 자체가 의미가 없다고 여김. 사실 더 큰 이유는 내가 직접 사용하지 않는 나머지 80% 기능을 구현할 의지가 없기 때문임
마케팅 쪽에서 Modified Pareto라는 개념이 있음. 80/20이 아니라 60/20임. 20%의 헤비유저가 60%의 제품 가치를 소비하고, 80%의 라이트유저는 40%를 소비함. 무시하기에 작은 비중이 아니므로, 가벼운 사용자도 반드시 신경 써야 함 value-paretos-bottom-80
이런 원칙을 진리로 보기보다는 반복되는 피드백 루프의 일부로 보는 것이 항상 흥미로움.
관찰: 80% 사용자가 소프트웨어 40%만 사용함
결론: 그 60% 중 일부를 잘라내자
관찰: 80% 사용자가 남은 40% 중 일부만 사용함
결론: 다시 자르자...
이런 식임. 실제로는 사용자가 소프트웨어가 자신의 문제를 해결할 수 있다고 '인지'하는 게 훨씬 더 중요함. 만약 돈을 쓰게 만들고 싶으면, 소프트웨어가 잠재적으로 사용자의 다양한 문제도 해결할 수 있다는 느낌을 줘야 함. 그런 다양한 문제는 사용자가 직접 사용하지 않는 기능이더라도 해당될 수 있음. 예를 들어 3D 소프트웨어에서 본 리깅 시스템은 2% 사용자가 1%의 시간밖에 안 쓸지라도, 그 기능 없으면 아예 제품을 검토조차 안 하는 사람들이 있을 수 있음
IT 정책과 거버넌스도 이런 Desire path 기반으로 작성하라고 추천함. 다만 환경이 복잡해질 경우 확장성이나 비용 측면에서 문제가 생길 수 있음
이건 현실 세계에서 이루어지는 텔레메트리(사용자 행태 추적)와 비슷하고, 선택적으로 빠져나갈 방법이 없음. 만약 선두주자가 아니라면 남이 걸어 놓은 길만 따라갈 수도 있음
"기능이 늘어나는 걸 막기보다는, 소프트웨어가 상상도 못했던 방식으로 사용될 수 있다는 걸 받아들여야 한다"는 내용에 공감함. 그래서 나는 상호운용성(interoperability)이 소프트웨어의 가장 중요한 요소라고 생각함. 본문의 주요 문제는 소프트웨어별, 버전별 파일 포맷의 폐쇄성이라는 인식을 받음. 나는 도구 여러 개를 조합해서 사용하는 걸 꺼리지 않지만, 도구들이 파이프라인에서 잘 협업을 못한다는 게 문제임. Unix의 꿈은 정말 어렵다는 생각임
어느 정도 규모가 있는 앱에서 모든 기능이 100% 활용되는 일은 거의 없음. 내 경험상 거의 모든 애플리케이션에는 10~30% 정도 완전히 활용되지 않는 부분이 있음. 이는 주로 개발팀 빼고는 아무도 알기 힘든 방식이거나 워크플로우가 형편없고 비효율적이거나, 혹은 너무나 기본적인 기능이라 실제로 필요한 회사는 그 소프트웨어를 구입할 경제력이 아예 없을 정도임
맞음, 하지만 많은 사용자가 각자 다르게 중요하게 여기는 20%의 기능이 있으니, 모든 기능을 유지해야 지금의 사용자 수를 지킬 수 있음. 그래도 유지보수나 개발에 많은 시간을 잡아먹는, 거의 안 쓰이는 기능을 없애면 ROI가 상승함
하지만 사용자들은 반드시 같은 20%를 중요하게 생각하는 건 아님. 또 한 가지 생각해볼 점은, 사용자는 실제로 앱을 사용해 보기 전엔 어떤 기능이 있는지 잘 모름. 설치 결정은 앱에 실제로 있는 기능이 아니라, 설치 전 스스로 기대하는 기능에 기반해서 이뤄짐. 이게 중요한 차이임. 기능에 노력을 들여도, 실제로는 유저를 확보한 뒤에야 결실을 얻게 됨.
MVP(최소 기능 제품) 만들 때 특히 중요한데, 대부분의 경우 설치와 지속 사용을 막는 건 기능의 부족이 아님. 보통은 메시지 전달, 마케팅, 혹은 아예 사용자가 끌릴 만한 가치가 없는 경우임. 기능을 마구 추가해도 이런 문제는 해결 안 됨. 이건 단순해 보여도 많은 회사가 놓치는 부분임.
가장 단순한 MVP는 일단 아무것도 구현하지 않아도, 사람들이 사전 등록하도록 유도하는 것부터임. 이런 방식으로 메시지가 제대로 전달되고 있는지 검증할 수 있음. 가입 후 실망한다면, 최소한 메시지는 잘 전달된 셈임.
다만 이렇게 하면 MVP가 약속한 만큼 완성돼 있지 않은 상태로 출시하게 되고, 미완성된 약속으로 실망감을 줄 위험이 생김. 또, 많은 기능이 사실 없어도 그만인 경우가 많은데, 특히 SaaS에서는 실제로 돈을 지불할 만큼 필수적이지 않은 기능이 많음. 고객의 요구사항을 곧바로 필수 요건으로 받아들이는 대신, 그들이 진짜로 '가치' 있다고 생각하는지, 실제로 비용을 지불할 의사가 있는지, 정말 중요한 고통점을 해결하는지 등을 꼭 명확히 파악해야 함. 고객의 요청이 왜 나왔는지를 이해하는 게 곧바로 그 기능을 만드는 것보다 훨씬 더 중요함
"사용자들이 같은 20%를 중요하게 생각하는 게 아니라"라는 한 문장만 보고 긴 댓글을 쓴 건지 궁금함
Hacker News 의견
내가 일했던 한 SaaS 회사에서는, 사용자들이 실제로 사용하는 기능의 일부만을 기준으로 분석을 시도했던 적이 있음. 몇 가지 핵심 사용자 유형에 맞춰 제품 복잡성을 줄이고, 성가신 기능도 없애고자 했음. 결과적으로 로그인 화면을 제외하면, 모두 각자 중요하게 생각하는 20%가 전혀 달랐음. 분석 결과는 가중치를 둔 무작위 추출과 다를 바가 없었음
정말 공감함. 그런데 엔터프라이즈 고객에게 제품을 판매하기 시작하면 상황이 완전히 바뀜. "위생적 기능" 하나 부족하면 거래가 무산될 수 있음. 그리고 각 엔터프라이즈마다 꼭 필요한 기능이 다 다름. 위생적 기능은 화장실처럼 누구나 필요로 하는 최소 필수 요소를 비유함
Spolsky 블로그 글들을 떠올리게 하는 비슷한 글임
strategy-letter-iv-bloatware-and-the-8020-myth
simplicity
개인적인 취미 앱을 직접 만들어 봤는데, 종종 다듬어서 공개해보고 싶다고 생각함. 하지만 내 앱을 홍보하거나 알릴 의지가 전혀 없어서 공개 자체가 의미가 없다고 여김. 사실 더 큰 이유는 내가 직접 사용하지 않는 나머지 80% 기능을 구현할 의지가 없기 때문임
마케팅 쪽에서 Modified Pareto라는 개념이 있음. 80/20이 아니라 60/20임. 20%의 헤비유저가 60%의 제품 가치를 소비하고, 80%의 라이트유저는 40%를 소비함. 무시하기에 작은 비중이 아니므로, 가벼운 사용자도 반드시 신경 써야 함
value-paretos-bottom-80
이런 식임. 실제로는 사용자가 소프트웨어가 자신의 문제를 해결할 수 있다고 '인지'하는 게 훨씬 더 중요함. 만약 돈을 쓰게 만들고 싶으면, 소프트웨어가 잠재적으로 사용자의 다양한 문제도 해결할 수 있다는 느낌을 줘야 함. 그런 다양한 문제는 사용자가 직접 사용하지 않는 기능이더라도 해당될 수 있음. 예를 들어 3D 소프트웨어에서 본 리깅 시스템은 2% 사용자가 1%의 시간밖에 안 쓸지라도, 그 기능 없으면 아예 제품을 검토조차 안 하는 사람들이 있을 수 있음
내 작업물이 실제로 어떻게 쓰일지 예측하는 데 소질이 없어서, 흔히 "Desire paths"로 비유되는, 드러난 경로에 길을 닦는 방식만 선호함
the-road-most-traveled-by-paving
"기능이 늘어나는 걸 막기보다는, 소프트웨어가 상상도 못했던 방식으로 사용될 수 있다는 걸 받아들여야 한다"는 내용에 공감함. 그래서 나는 상호운용성(interoperability)이 소프트웨어의 가장 중요한 요소라고 생각함. 본문의 주요 문제는 소프트웨어별, 버전별 파일 포맷의 폐쇄성이라는 인식을 받음. 나는 도구 여러 개를 조합해서 사용하는 걸 꺼리지 않지만, 도구들이 파이프라인에서 잘 협업을 못한다는 게 문제임. Unix의 꿈은 정말 어렵다는 생각임
어느 정도 규모가 있는 앱에서 모든 기능이 100% 활용되는 일은 거의 없음. 내 경험상 거의 모든 애플리케이션에는 10~30% 정도 완전히 활용되지 않는 부분이 있음. 이는 주로 개발팀 빼고는 아무도 알기 힘든 방식이거나 워크플로우가 형편없고 비효율적이거나, 혹은 너무나 기본적인 기능이라 실제로 필요한 회사는 그 소프트웨어를 구입할 경제력이 아예 없을 정도임
맞음, 하지만 많은 사용자가 각자 다르게 중요하게 여기는 20%의 기능이 있으니, 모든 기능을 유지해야 지금의 사용자 수를 지킬 수 있음. 그래도 유지보수나 개발에 많은 시간을 잡아먹는, 거의 안 쓰이는 기능을 없애면 ROI가 상승함
하지만 사용자들은 반드시 같은 20%를 중요하게 생각하는 건 아님. 또 한 가지 생각해볼 점은, 사용자는 실제로 앱을 사용해 보기 전엔 어떤 기능이 있는지 잘 모름. 설치 결정은 앱에 실제로 있는 기능이 아니라, 설치 전 스스로 기대하는 기능에 기반해서 이뤄짐. 이게 중요한 차이임. 기능에 노력을 들여도, 실제로는 유저를 확보한 뒤에야 결실을 얻게 됨.
MVP(최소 기능 제품) 만들 때 특히 중요한데, 대부분의 경우 설치와 지속 사용을 막는 건 기능의 부족이 아님. 보통은 메시지 전달, 마케팅, 혹은 아예 사용자가 끌릴 만한 가치가 없는 경우임. 기능을 마구 추가해도 이런 문제는 해결 안 됨. 이건 단순해 보여도 많은 회사가 놓치는 부분임.
가장 단순한 MVP는 일단 아무것도 구현하지 않아도, 사람들이 사전 등록하도록 유도하는 것부터임. 이런 방식으로 메시지가 제대로 전달되고 있는지 검증할 수 있음. 가입 후 실망한다면, 최소한 메시지는 잘 전달된 셈임.
다만 이렇게 하면 MVP가 약속한 만큼 완성돼 있지 않은 상태로 출시하게 되고, 미완성된 약속으로 실망감을 줄 위험이 생김. 또, 많은 기능이 사실 없어도 그만인 경우가 많은데, 특히 SaaS에서는 실제로 돈을 지불할 만큼 필수적이지 않은 기능이 많음. 고객의 요구사항을 곧바로 필수 요건으로 받아들이는 대신, 그들이 진짜로 '가치' 있다고 생각하는지, 실제로 비용을 지불할 의사가 있는지, 정말 중요한 고통점을 해결하는지 등을 꼭 명확히 파악해야 함. 고객의 요청이 왜 나왔는지를 이해하는 게 곧바로 그 기능을 만드는 것보다 훨씬 더 중요함