Amplitude, Mixpanel, Google Analytics, Posthog 등 사용자 행동 분석 툴 세팅하시려는 분들 중 다음에 해당하시는 분들을 찾습니다!

• 도구 세팅이나 수집 요청에 들이는 시간과 노력이 아깝다

• 이를 해결하려면 개발자 등 다른 동료에게 부탁해야 한다

• 이미 수많은 이벤트 목록을 관리하고 있다

🇺🇸이번 실리콘밸리 체류 경험을 1:1 화상으로 공유드리고 싶습니다

안녕하세요, Measured를 만들고 있는 메저드 팀의 임종혁입니다.

올 여름부터 저희 제품(공식 홈페이지, 디스콰이엇, 데모 영상)을 가지고 샌프란시스코 체류를 시작했습니다.

(저희 제품인 메저드는 앱이나 웹 제품에서의 사용자 행동 정보를 UI를 통해 실시간으로 수집 세팅할 수 있는 도구입니다. 개발을 몰라도 누군가에게 요청하거나 개발/배포 과정을 거칠 필요없이 직관적인 UI를 통해 원하는 분이 직접 이벤트 트래킹을 세팅하고 관리할 수 있게 됩니다.)

미국 시장에서 경쟁력을 가질 수 있는지 검증하고, 이에 맞는 고객을 확보하는 목표를 가지고 왔습니다. 책이나 사고 실험만으로 매듭 지을 수 없는 고민들을 해소하기 위해 직관에 따라 오게 됐고,

2개월이 지나고 있는 지금, 결론부터 말하면 저희가 한 최고의 결정 중 하나가 되었습니다.

1년의 기간 동안 100팀 미만 대상으로 Closed beta를 진행했고 이번 체류 기간 동안 공개 버전도 출시가 되었는데요,

저희 제품에 대한 피드백도 구할 겸, 저희의 실리콘밸리 체류에 관한 최신 플레이북이 필요한 팀을 찾고자 합니다.

다음 상황들에 속하신 분들이시라면 아래 링크로 들어와 간단한 양식을 적어주시면 연락드리도록 하겠습니다!

• (1) 글로벌 제품을 만들고 싶은 욕심이 있는 분 (해외 이전 없이 국내에서 실행하는 것이 목표여도 무관)

• (2) 실리콘밸리 체류가 나의 제품/사업에 도움이 될지 고민 중인 분

• (3) Web/App 제품을 보유했으면서 제품에 Measured SDK를 설치할 분 (출시 직전의 테스트or스테이징 제품을 보유하신 분 포함)

🔗 실리콘밸리 체류 경험 무료나눔 신청하러 가기 👈

Reddit 정책에 대해 잘 아시는 분 계신가요?

Reddit에 있는 서브레딧 중 r/webdev에 Showoff Saturday라고 해서, 매주 토요일에 제품 홍보글을 자유롭게 게시할 수 있는 정책이 있다고 들었습니다.

이전에 올라온 게시글들을 보니 댓글이 60개 이상으로 상당히 활발하게 달리는 걸 확인했었는데요,

방금 저희도 PDT 기준으로 다음처럼 올렸는데, 링크는 살아있지만 서브레딧 목록에 최신순 정렬을 해도 보이지 않습니다..

https://www.reddit.com/r/webdev/comments/1fh6mmx/i_made_a_google_tag_manager_alternative_link_in/

혹시 승인 제도가 있거나 특정 시간대 기준으로 토요일인지 아시는 분이 계실까요?

조선시대에 스티브 잡스가 등장한다면

조선시대에 스티브 잡스가 등장한다면 '허생전'에 등장하는 허생의 모습이 아닐까.

1.

"내가 집이 가난해서 무얼 좀 해 보려나 하니, 만 냥을 뀌어 주시기 바랍니다."

⋯

“아니, 이제 하루 아침에, 평생 누군지도 알지 못하는 사람에게 만 냥을 그냥 내던져 버리고 성명도 묻지 않으시다니, 대체 무슨 영문인가요?”

"이건, 너희들이 알 바 아니다. 대체로 남에게 무엇을 빌리러 오는 사람은 으레 자기 뜻을 대단히 선전하고, 신용을 자랑하면서도 비굴한 빛이 얼굴에 나타나고, 말을 중언부언하게 마련이다. 그런데 저 객은 형색은 허술하지만, 말이 간단하고, 눈을 오만하게 뜨며, 얼굴에 부끄러운 기색이 없는 것으로 보아, 재물이 없어도 스스로 만족할 수 있는 사람이다. 그 사람이 해 보겠다는 일이 작은 일이 아닐 것이매, 나 또한 그를 시험해 보려는 것이다. 안 주면 모르되, 이왕 만 냥을 주는 바에 성명은 물어 무엇을 하겠느냐?"

👉 제품 소개, IR 등에 반영할 수 있기 위해 내적으로 먼저 확립해야 되는 판단력과 실행력과 비전의 수준

2.

"덕이 있으면 사람이 절로 모인다네. 덕이 없을까 두렵지, 사람이 없는 것이야 근심할 것이 있겠나?"

👉 세상에 의미 있는 목표를 가지고 있고 제품이 본질적으로 가치 있냐가 중요하지, 없던 시장이라는 사실과 초기고객이 모여있지 않은 상황이 중요한 것은 아니다.

3.

"소위 사대부란 것들이 무엇이란 말이냐?

⋯

이튿날, 다시 찾아가 보았더니, 집이 텅 비어 있고, 허생은 간 곳이 없었다."

👉 장기적인 비전 없이 각종 Tech Hype에 휩쓸려다니며, 반응 오는 것만을 빨리 찾고 추종하는 것이 창업의 본질적인 목표라는 생각이 만연했던 시류에 대한 멸시와 초월적인 태도.

🔗 허생전 전문

Supabase는 초기 50명까지 개발자 아니면 채용 안 했습니다.

Supabase는 작년에 Series B로 1,040억원 정도를 투자 받은 팀이자 서비스명입니다.

이제 주변에서도 백엔드 설계를 고민할 때 Supabase를 활용하는 분들을 쉽게 찾아볼 수 있는 것 같습니다. 저도 2021년에 Supabase를 처음 접한 뒤로 즐겨 쓰고 있는데요, 몇 달 전에 Supabase 관련 히스토리를 찾아볼 일이 있었습니다.

이 팀이 초기 50명까지는 엔지니어만 채용했다고 하는데(first ~50 people hired at Supabase were all technical), 과연 무슨 이유로 그런 결정을 내렸던 걸까요?

당시에 정리해 둔 이 팀의 역사를 아래에 Bullet points로 공유합니다.

2020년, 설립 초기의 이야기

1. Paul Copplestone, Ant Wilson이 2020년에 공동창업.

2. Paul은 어떤 오피스 관리 플랫폼(Nimbus for Work)에서 CTO로 일하고 있었음.

3. 일 관련해서 Google의 Firebase 써가지고 채팅 앱 만들려는데 메시지를 실시간으로 가져오기 어렵게 만드는 Firebase의 제약(1 query per 1 document limitation)을 마주치면서 고민에 빠짐.

4. Firebase는 서버 DB 내용이 클라이언트에 실시간 동기화가 자동으로 된다는 편리한 점이 있지만, 이렇게 원하는 상황에 활용하기 어렵게 되면서 다른 방법을 찾다가 일단 DB를 Postgres로 교체.

5. 그치만 Postgres는 실시간 동기화 같은 게 없음. 그래서 Postgres에 쓸 수 있는 실시간 동기화 엔진을 직접 만들기로 함.

6. 만들고 나서 오픈소스로 올려둔 다음 Hacker News(와이컴비네이터에서 운영하는 스타트업계에서 유명한 뉴스피드)에도 게시해봤더니 다른 사람들도 같은 문제를 겪고 있다는 걸 알게 됨. (62 upvotes, 21 comments) 그리고 이렇게 올린 게 계기가 되어서 Repo에 대한 관심이 점점 늘기 시작.

7. 몇 개월 뒤에 Ant라는 친구한테 아이디어를 공유하게 됐고 생각이 잘 통한다는 것을 서로 알게 됨. (Ant의 기억: 이 때 아이디어 얘기를 진짜 길게 했는데 보통은 그렇게 대화 마치고나면 잠깐 쉴 법도 하겠지만 Paul은 대화 끝나자마자 다시 컴퓨터 열고 코딩 시작하더라. 그 모습이 Ant 입장에서 인상에 깊게 남음. 둘은 그 전에 싱가포르에서 같이 살면서 엄청 친해졌었음)

8. 그렇게 둘이서 2020년 1월에 Supabase를 시작하게 됨.

9. 최초 비전은 Paul이 만든 MVP를 벗어난 수준의 제품을 만드는 것. 이 때의 제품은 Real-time Postgres로 얘기하러 다니기 시작함.

PMF 도달까지의 과정

1. 초기에 엄청 빠르게 움직였음: 코딩 시작하고 몇 개월 만에 $100,000(13억원) 엔젤투자도 받고 YC 배치도 들어가게 됨.

2. 그런데 예전에 Hacker News에서 받았던 반응이랑 투자 빨리 받은 결과가 실제 사용자가 쓰는 성과로 이어지지는 않았음. 4월에 호스팅하는 DB 수가 8개 였음. (고객이 8명 이하였다는 말. 한 고객이 여러 DB 쓸 수 있으니)

3. 그러다가 “Real-time Postgres”라는 표현을 “The Open-Source Firebase Alternative”로 바꿔 얘기하면서 엄청나게 성장하기 시작함. 이런 표현으로 Hacker News에 올렸더니 1,120명 이상이 upvote하면서 Hacker News 역사상 두 번째로 인기 있는 ‘Lanuch HN’ 포스트가 됨.

   • 당시 글: Supabase (YC S20) – An open source Firebase alternative

4. Supabase 팀이 생각했던 ‘사람들은 Firebase를 진짜 잘 쓰고 좋아하긴 하지만, 이것이 가지고 있는 단점들 때문에 늘 Firebase 대체제를 찾고 있었고, 그걸 제대로 만들고 있는 게 우리다.’라는 게 적중했던 거임.

5. Product Hunt에도 제품을 올렸더니 3위에 바로 오름.

6. 결과적으로는 3일 만에 호스팅 DB가 8개에서 800개로 늘어남. (100x)

7. 이런 초기 성공 덕분에 팀에 자신감도 생기고 비전도 더 넓히기 시작할 수 있게 됨.

참고자료

• How Supabase became this generation’s database | Basedash

• Supabase raises $80M Series B for its open source Firebase alternative | TechCrunch, May 11 2022

• Supabase - Crunchbase Company Profile & Funding

제목: 컴퓨터 세계를 함께 바꿀 동료를 찾습니다

워즈,

이 글을 쓰는 건, 우리가 대단한 일을 할 수 있다고 믿기 때문이야.
미래를 봤어. 컴퓨터가 모든 사람의 삶에 필수가 된 그 미래를 말이야.
그리고 그 미래를 만들 사람이 너라는 걸 확신해.

너의 기술적 재능과 내 비전이 만나면, 우리는 단순한 전자기기를 넘어 인간의 삶을 개선할 수 있는 제품을 만들 수 있어.
나는 너와 함께 비즈니스와 마케팅에서 일할 준비가 되어 있고, 네 엔지니어링 능력이 우리에게 필요한 마지막 퍼즐 조각이야.

이건 그냥 일자리 제안이 아니야. 이건 역사를 만들 기회지.
우리는 단순한 기기를 넘어 사람들의 생각과 행동 방식을 변화시킬 수 있어.
네 기술과 내 비전이 만나면, 우리는 성공을 넘어 시대를 정의하는 일을 할 수 있어.

우리는 단순한 동료가 아니라, 혁명을 이끌 동지가 될 거야. 네가 가진 것을 세상에 보여줄 준비가 됐는지 알려줘.

우리가 할 수 있는 일을 상상해봐, 워즈. 그리고 우리가 함께할 때 가능한 것들을 생각해봐.

네 답을 기다릴게.

- 스티브 잡스
1976년 3월 1일


----------


위 내용은 만약 스티브 잡스가 최초에 워즈니악을 설득하기 위해 글을 썼다면 어떤 내용이 담겼을지 GPT와 함께 상상으로 가다듬은 내용입니다.
저 또한 누군가를 설득하는 고민을 하는 요즘이다보니 이런 저런 사례가 눈에 들어오고 있는데요, 이렇게 GPT를 통해서 지향점이 비슷한 사례의 시작을 되짚어 보는 시도도 흥미롭고 유익한 것 같습니다.

대답이 어려우면 질문을 바꿔야 할 때

어떤 사람이 어떤 아이디어가 떠올라서 이를 실현하기 위해 창업에 뛰어든다고 칩시다.

혹은 어떤 사람이 아이템을 나중에 찾을 생각으로 일단 '창업'이라는 걸 시작하기로 마음 먹었다고 칩시다.

두 사람 모두 이후에 더욱 명확해진 목표에 몰입하는 상황이 오면 다행이겠지만, '주변 사람들에게 단언했으니', '이미 매몰비용이 크니깐', '몰입이 안 되는 것이라도 참으면서 일주일에 100시간 이상을 해내는 과정이 자고로 필요하다고 왠지 다들 얘기했던 것 같은 기억이 있어서'라는 이유로 계속 진행하는 경우가 많습니다.

간혹 이렇게 싫은 일을 참으면서 해내다가 당연히 수학적 확률로서 '잘 되는' 케이스가 나오기도 하지만, 우리가 로또를 위해 삶을 설계하진 않듯이 그런 상황을 지속하는 것은 자연스럽지 않습니다.

이럴 때엔 내가 정말 몰입하고 싶은 목표를 찾은 게 맞는지 자문할 필요가 있습니다.

왜냐면, 정말 자신에게 있어 중요한 목표를 발견한 게 맞다면 타인의 판단이나 시선에 무관하게 도전하게 되며, 매몰비용은 생각나지도 않고, 시간을 잰 적도 없는데 결과적으로 일주일에 100시간 이상을 매우 지속가능하게 그 목표에 몰입하게 되기 때문입니다.

일하는 공간 바닥에 이불을 깔고 잠을 자거나 버스나 지하철에서도 랩탑을 펼쳐 일을 하는 것이 어떤 기괴한 일화가 아니라, 당연하고 편안하며 자연스러운 일상이 되는 것입니다.

스티브 잡스가 스탠퍼드 연설에서 얘기한 다음 문장,

“And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it.”

그리고 빌 게이츠와 함께 나온 D5 컨퍼런스에서 열정이 생기지 않는 목표를 쥐고 있다면 제정신인 사람인 경우 포기할 수 밖에 없는 이유에 대해 얘기한 것과 일맥상통합니다.

"People say you have a lot of passion for what you’re doing, and it’s totally true and the reason is because it’s so hard that if you don’t any rational person would give up.

It’s really hard and you have to do it over a sustained period of time. So if you don’t love it, if you’re not having fun doing it, if you don’t really love it, you’re going to give up."

당신 자신과 당신의 목표는 어떤 상태입니까?

골목식당에서 배우는 스타트업 정신

아이디어가 떠올라서 핵심 제품을 빠르게 만든 뒤, 이를 누군가에게 전달하고, 전달 받는 고객을 만나서 의견을 듣고 수정하길 신속히 반복하는 것이 스타트업 업계에서 기본으로 여겨진지 오래입니다. (흔히 '린 스타트업 방법론'이라고 불리우는)

그런데 '스타트업'이라는 키워드로 연상되는 정보나 분야 밖에서도 충분히 이런 통찰을 얻을 수 있는데요, 그와 관련된 '백종원의 장사이야기' 시리즈 중 한 편을 소개드립니다.

돈을 지불하는 고객을 가장 가까이에서 지켜보며 고객이 말하지 않는 여러 정황(데이터)들 속에서 유의미한 피드백을 찾아내고 그것을 다음 이터레이션(다음 식사)에 즉시 반영하는, 이런 모습을 보다보면 오히려 '스타트업' 업계에서 발견해냈다는 '린' 뭐시기로 통용되는 기본이라는 것이 사실 다른 분야에 비해서 뒤늦게 정리된 것이 아닐까하는 생각이 들게 됩니다.

마찬가지로 보석을 가공해서 납품하는 업계나 하드웨어를 제작하는 회사들을 떠올릴 때, '스타트업'이라는 것에 몸 담고 있는 사람들 입장에서는 그 업계나 회사들에 '느린 산업'이라는 고정관념을 가지고 있을 수 있는데요(제가 그랬었습니다), 알다보면 그렇지 않더라고요.

아무튼 위에 영상이 정말 재밌으니 2배속을 해서라도 보시기 바라며, 더욱 겸손해야 겠다는 생각을 하는 요즘입니다.

제품 개발 시 NOT TO DO 리스트 for 초기 팀

목표를 세웠다면 하지 말아야 할 것을 안 하는 것만큼 어려운 것이 없습니다.

이런 결정을 잘 하고자 할 때, 공식이 없는 길을 걸어가는 도전―e.g. 스타트업―에 뛰어든 분들 일수록 과거의 사례들이 오히려 독이 되는 경우가 많은 것 같습니다.

모든 영역에서 필요한 사고겠지만 저도 그동안 개발을 하며 쌓인, '하지 말아야 할 것을 수도 없이 해버린' 실패 경험에서 뽑아본 NOT TO DO 목록을 아래에 공유해봅니다.

1. 테스트 코드를 작성하지 말 것.

2. 패키지 폴더명이나 구조에 시간을 쓰지 말 것.

3. 좋은 아키텍쳐 선정에 시간을 쓰지 말 것.

4. 익숙하진 않지만 좋을 것 같은 신기술을 선택하지 말 것.

5. 확장성을 고려하지 말 것.

6. 장기적인 기술 로드맵을 그리지 말 것.

7. 실제 고객이 경험하고 필요성을 얘기하는 것과 관련된 개발의 우선순위를 높일 것.

8. 견고하게 만들지 말 것.

9. 문서를 쓰지 말 것.

하나하나가 한 편의 글이 될만큼 많은 실패가 있었던 것 같습니다.

또 다른 NOT TO DO가 무엇이 있을까요?

핑계 댈 수 없는 시대에 관한 단상

불과 10년 전까지만 해도, 웹 사이트나 모바일 앱을 새로 제작하려면 지금보다 훨씬 많은 시간과 노력이 들었던 것 같습니다. React Native나 Flutter 같은 크로스플랫폼 프레임워크가 없던 시절이기 때문에 모바일 앱을 만들려면 하이브리드 웹 앱으로 만들지, 아니면 Android와 iOS 중 하나만 네이티브 개발로 출시할지 고민하기도 하고, AWS가 보편적이지 않았던 시절이었기 때문에 베어본으로 서버를 직접 구축하거나 가격을 잘 알아보면서 서버 호스팅 업체를 선정하는 것부터 시작했었습니다. 서버 언어로는 큰 회사가 아닌 한 PHP를 쓸지, 아니면 Python, Ruby 기반의 무언가를 쓸지 고민해야 했는데, 당시에 막 떠오르기 시작한 Node.js라는 모험을 택하는 팀들도 있었습니다.

지금은 상황이 많이 바뀌었죠. 오래된 제품을 유지보수하는 게 아닌 한 새로운 제품을 만들고자 할 때 이에 필요한 기능을 밑바닥부터 구현해서 쓰는 경우는 매우 드뭅니다. 오히려 '직접 구현하지 않고 해결할 방법이 없을까?'라는 질문을 항상 던지게 되는 것 같습니다. 그 이유는 우리가 떠올릴 수 있는 고민의 해결책이 대부분 만들어져 있는 세상이 되었기 때문이 아닐까 합니다. ChatGPT도 이런 시류에 부합하는 가능성을 보여줬습니다. 목표 달성에 있어서 How를 고민하지 않고도 적당한 결과물을 유례없는 속도와 정말 적은 노력으로 받아볼 수 있게 된 것입니다. 개인적으로는 20년 전에 제로보드, 테터툴즈 등을 설치해 쓰던 시절에서 10년 전으로 넘어올 때의 변화보다, 10년 전에서 지금으로의 변화가 더 크게 느껴집니다.

이렇게 How에 대한 문제가 해소되니 더 좋은 목표를 찾아내는 일이 갈수록 중요해지고 있습니다. 내가 풀려는 문제가 정말 세상에 의미 있는 문제인지, 이 문제가 지금 타이밍에 풀만한 가치가 있는지, 앞으로 많은 어려움이 있더라도 내가 그 문제에 도전해야 할 진정한 이유가 있는지 등. 과거와 달리 '방법은 어떻게든 있다'를 전제로 두는 시대가 온 것입니다. Problem과 Solution의 관계에서 Solution 자체에 갇히지 말고 열린 자세를 취해야 한다는 인식이 보편화된 것도 한몫했을테고요.

이것을 다른 관점에서 보면 핑계 댈 수 없는 시대가 왔다는 말이기도 합니다. '이래서 안 되고 저래서 안 되고'라는 가능 여부에 대한 얘기보다는 '정말 그 문제를 풀고 싶은 게 맞니?', '그렇게 포기한다면 애초에 애정 없는 목표를 가졌던 것 아니야?' 같은 질문들이 더욱 중요해집니다. 모두의 손에 How가 쥐어졌으니, 세상에 더욱 다채로운 Output이 나올 것 같지만, 아이러니하게도 이런 중요한 질문들까지 함께 보편화되다 보니 How의 양에 비례하여 풍요로운 결과가 사회에 공급되고 있는 게 맞을까 궁금해집니다.

이에 관해서 네이트 실버의 <신호와 소음>에 나온 몇 가지 구절이 떠오릅니다.

인쇄술이 촉발한 정보의 폭발적 증가는 우리에게 엄청난 이익을 가져다준 것으로 판명 났다. 그 이익이 실현되는 데 무려 330년이 걸리고 유럽 전역의 전장에서 수백만 명이 목숨을 잃었지만 말이다.

오히려 1970년대와 1980년대의 컴퓨터 붐이 경제와 과학의 생산성에서 일시 후퇴를 낳았다. 경제학자들은 이 현상을 ‘생산성 역설productivity paradox’이라 부른다.

빅데이터는 발전을 낳는다. 하지만 여기에는 ‘궁극적으로 볼 때’라는 단서가 붙는다. 발전 시기가 얼마나 앞당겨질지, 그 중간에 퇴보할지 아닌지는 우리가 어떻게 하느냐에 달렸다.

웹이나 앱 제품을 만든다는 것은 결국 누군가를 설득하는 일을 하는 것이기도 합니다. 그렇기 때문에 우리 스스로 너무 기술만능주의에 따라서 사고하고 있는 것이 아닌지, 지금 목격하고 있는 신기술이 요란한 수레나 신기루에 불과한 게 아닌지, '해야 할 것'보다 '하면 좋은 것'에 치중하고 있는 게 아닌지 끊임 없이 고찰하고 주변에 피드백을 요청하는 노력만큼 중요한 게 없어 보입니다.

자신의 신념을 강하게 밀어붙여야만 나아갈 수 있으면서도 언제나 자기 자신이 틀릴 수밖에 없음을 자연스럽게 받아들여야 하는 이상한 길목에 들어선 여러분 모두를 응원합니다.

데이터 분석, 도구 세팅은 시작에 불과하다

저희 팀은 사용자 행동 데이터 수집과 분석 과정을 혁신하기 위해 노코드 이벤트 트래킹 툴인 Measured(메저드)를 만들고 있습니다. 제품을 만드는 사람들 누구나, 사용자가 우리 제품을 정말 잘 쓰고 있는지 알기 위해 어떻게 행동 데이터를 수집하고 분석할지 고민하게 됩니다. 저희도 이런 고민을 겪는 여러 조직들의 목소리를 오랫동안 듣다보니 그 과정에서 일어나는 세세한 사건들을 꽤 축적할 수 있었는데요, 오늘은 그 중에서도 데이터를 이제 막 수집하고 분석하려는 니즈가 생기는 팀이 공통적으로 겪게 되는 과정 세 가지를 정리해보았습니다.

제품을 만들다보면 행동 분석이 필요한 시점이 생각보다 일찍 옵니다.

제품을 출시한지 얼마 안 됐거나 출시하기 전이라면 주요 기능을 완성하기에도 빠듯할 때 입니다. 그러다보니 이런 초기 타이밍엔 팀 여력에 따라 데이터 수집 & 분석 세팅 작업의 우선순위가 밀리곤 합니다. 왜냐면 이 작업의 우선순위를 높이기에는 어떤 것을 분석하고 싶은지에 대한 고민, 이를 위한 여러 역할 간의 의사소통, 개발 내용에 반영하기 위한 시간과 노력 등 실행의 무게가 생각보다 가볍지 않고, 그와 동시에 아직 사용자 수가 너무 적은 시점이다보니 수집 이후에 효용을 얻기 위한 명확한 근거를 찾기 애매하기 때문입니다. 하지만 막상 제품을 출시하고나면 사용자가 열 명만 넘어가도 제품 만드는 입장에서 궁금한 점이 계속 쌓이기 마련입니다. 수학적으로 30명 이상은 되어야 결과가 유의미하다곤 하지만 그 전에 당장 제품을 전달한 열 명이 의도대로 제품을 쓰고 있는지, 공통적으로 막히는 지점이 있지 않은지, 예상과 다르게 어떤 행동을 더 하고 있을지에 대한 질문이 쌓이게 됩니다. 인터뷰를 매일 요청하는 것도 한계가 있다보니 데이터 수집에 대한 고민이 일찍 떠오를 수 밖에 없게 됩니다.

쌓인 데이터를 어떻게 활용할지도 계속 고민입니다.

위와 같은 상황에서도 품을 들여 Google Analytics, Amplitude, Mixpanel 등의 데이터 수집 도구를 세팅하고 나면 본격적으로 데이터 수집이 시작되고, 그러면서 새로운 문제들을 마주하게 됩니다. 분석을 하고자 할 때, 사전 논의대로 데이터가 정확히 수집되고 있는지, 분석 도구의 세팅 값에서 누락된 게 없는지(이 세팅대로 나온 결과를 정말 믿어도 되는지), 지금 제품 목표를 위해 어떤 행동을 분석하는 게 더욱 의미있을지, 지금 도입된 기술로 어떤 분석까지 가능할지, 분석 도중에 니즈가 생긴 새 행동 데이터 수집이나 기존 수집의 수정 작업을 팀 내에서 어떤 우선순위로 진행되게 할 수 있을지 등. 제품이 계속 변경되고 데이터가 더 많이 수집될수록 끊임없이 다양한 문제를 마주하게 되고 이런 고민이 적시에 해소되지 못하면 데이터 수집과 분석 사이에 해소하기 어려운 산맥이 쌓이게 된 채, 데이터 기반 의사결정이라는 말이 무색해지는 문화에 젖어들게 됩니다. 도구 세팅을 다 해놓고 충분한 효용을 못 얻는 이런 상황은, 신형 아이맥을 사서 매장에 메뉴판 띄우는 용도로 쓰는 것과 같은 격입니다.

팀의 내적 동기가 정말 중요하다는 걸 알게 됩니다.

인터넷을 조금만 뒤져봐도 데이터 수집 도구를 세팅하고 분석 과정을 따라하게 해주는 가이드는 정말 많습니다. 하지만 그런 방법들 모두, 지금 이 순간의 우리 제품과 우리 팀에 딱 맞기엔 어려운 경우가 보통입니다. 데이터 기반으로 의사결정하는 문화가 정착되기 위해선 어느 정도 반직관적인 노력이 필요합니다. 마치 한 사람이 스스로의 운동 루틴을 만드는 것과 같아서 당장 들어가는 노력대비 눈에 보이는 효용이 없어보여도 그 자체의 중요성과 장기적인 목표에 대한 의지를 가지고 포기하지 않은 채 습관화하는 시간이 필요합니다. 그런데 도구를 다 준비했다고 해서 이런 습관이 저절로 형성되진 않습니다. 가장 좋은 방법은 단편적인 컨설팅이나 외부 의견에 의존하지 않고 이미 이 효용을 알고 내적 동기가 충분한 구성원이 내부에 있는 상황일텐데요, 채용에 관한 얘기이므로 이 또한 절대 쉬운 일이 될 수 없습니다.

이미 이런 문제들을 겪어 보셨거나 겪는 중인 팀들이 많이 계실 것입니다. 저희 팀은 Measured라는 서비스명으로 이 모든 문제를 일회성으로 끝나지 않게 지속 해결할 수 있는 방법을 제공하고 있는데요, 더 관심 있으신 분들은 글에 첨부된 메저드 디스콰이엇 제품 페이지를 찜해주시거나 댓글을 달아 구독해주세요!

(2부) '아무도 원치 않는 제품 만들기'를 피하는 방법

지난 번에 공유한 요약의 2부가 올라와서 간단히 요약한 내용을 리로그 드립니다.

초기 제품 개발 과정과 성장에 고민이 많으신 분이라면 다음 비공개 클럽에도 꼭 Join 해서 고민을 얘기하고 아이디어를 얻어보세요! 👇👇👇👇

왜 안 쓸까 내 제품 | Disquiet*

제품을 열심히 만들었는데 아무도 안 쓴다고요? 일어날 일이 일어났군요. 그렇다면 이 클럽에 들어 오셔야 합니다. 각자 만들고 있는 제품의 현재 상황을 공유하고 대책을 주고 받으며 좌절을 극복해봅시다.

https://disquiet.io/club/zero-user-product

(2부) '아무도 원치 않는 제품 만들기'를 피하는 방법

클럽 취지에 맞는 이 시리즈의 1부를 저번에 요약해서 소개드렸었는데요, 2부도 올라왔길래 간단히 요약을 남겨봅니다.

2부👇

How to avoid creating products that no one wants with JTBDs

In part 1 of this series, we focused on what is a 'need' and how to get a glimse into what people want by using situational segments. To get the *real*...

https://www.indiehackers.com/post/how-to-avoid-creating-products-that-no-one-wants-with-jtbds-627a44aeca

지난 1부 요약👇

'아무도 원치 않는 제품 만들기'를 피하는 방법 | Disquiet*

제목과 같이 좋은 글을 읽게 돼서 공유합니다. 링크로 들어가 직접 읽어보시길 추천드려요!🔗 How to avoid creating products that no one wants‘해결책’이 아니라 ‘니즈’를 먼저 생각해라. 사람들이 원하는 ‘니즈’라는 것은 시간이 지나도 잘 바뀌지 않는다.사람들은 부동산 찾기,...

https://disquiet.io/@stargt/makerlog/6973

1. 많은 창업자가 사람들이 딱히 해결할 필요를 못 느끼는 문제를 풀려고 한다 ㅠ
2. 문제의 크기만 생각하지 말고, 지금의 해법에 만족하고 있는지도 확인해라.
3. 사람들한테 중요한 니즈라고 해도, 기존 해결책으로 충분히 만족하며 살고 있다면 풀 가치가 없는 문제다.
4. 예를 들어 ‘현재 날씨를 아는 게’ 중요할 순 있어도, 구글링 같은 거로 간단하게 해소할 수 있으면 새로운 방법을 만들어봤자 가치가 크지 않다는 얘기다.

이 2가지 외에는 문제/솔루션을 판단할 때와 인터뷰를 진행할 때 실무적인 팁들이 구체적으로 나열되어 있습니다. 직접 보시길 추천드립니다!

'아무도 원치 않는 제품 만들기'를 피하는 방법

좋은 글을 보게 돼서 요약해본 내용을 공유드립니다. 요약보다는 실제 내용이 참 사이다 같아서 직접 꼭 읽어 보시길 추천드립니다.

초기 제품 개발 과정과 성장에 고민이 많으신 분이라면 다음 클럽에도 꼭 Join 해주세요!

👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇

왜 안 쓸까 내 제품 | Disquiet*

제품을 열심히 만들었는데 아무도 안 쓴다고요? 일어날 일이 일어났군요. 그렇다면 이 클럽에 들어 오셔야 합니다. 각자 만들고 있는 제품의 현재 상황을 공유하고 대책을 주고 받으며 좌절을 극복해봅시다.

https://disquiet.io/club/zero-user-product

'아무도 원치 않는 제품 만들기'를 피하는 방법

제목과 같이 좋은 글을 읽게 돼서 공유합니다. 링크로 들어가 직접 읽어보시길 추천드려요!

🔗 How to avoid creating products that no one wants

‘해결책’이 아니라 ‘니즈’를 먼저 생각해라. 사람들이 원하는 ‘니즈’라는 것은 시간이 지나도 잘 바뀌지 않는다.

• 사람들은 부동산 찾기, 피부 노화 막기, 안전하게 돈 관리하기, 옷 얼룩 제거 등의 ‘해결이 필요한 일(jobs to be done)’을 해결하고 싶어하기 때문에 이를 위한 방법을 찾아 ‘고용(hire)’한다.
• e.g. ‘더 잘 맞는 연애 상대를 찾고 싶다’라는 니즈는 쭉 있어왔고 세월이 흐르면서 파트너찾는뉴스광고→중개소→데이팅앱으로 이동해왔다. 뒤로 갈수록 이전 방법들에 비해 더 결과가 좋고 저렴한 솔루션.
• e.g. ‘이동 중에 음악 듣고 싶다’: 워크맨→MP3 플레이어→아이팟→스마트폰
• 회사 프로젝트 관리 잘하기(Basecamp), 로고 찾기(DALL-E), 사업 초기 성장시키기(Indie Hackers) 등도 마찬가지

사람들한테 ‘무슨 기능이 필요하세요?’ 같은 질문 좀 하지 마라

• 이런 질문은 사람들한테 문제, 기존 제품, 적합한 해결책을 동시에 평가하고 얘기하도록 강요하는 것. 이건 니 몫이다.
• 전자레인지라는게 나오기 전에 사람들은 “요리 시간 단축 & 음식 너무 익히는 것 방지”를 원했지 전자레인지를 얘기할 수 있는 건 아니었다. 전자레인지를 고안해내는 건 니 몫이다.
• 심지어 사람들은 질문하는 니네한테 어떻게 비칠 지를 신경써야 하기 때문에 ‘이 제품/가격 어떻게 생각하세요?’, ‘이 기능 어떻게 개선하면 좋겠나요?’ 같은 질문에 자신이 손해 안 볼 대답을 해내기 위해 노력까지 한다.

타겟 생각할 때 ‘어떤 부류의 사람들’이 아니라 ‘어떤 문제 상황을 겪을 때’로 생각을 바꿔라: demographic segments(X) → situational segments(O)

• ‘10대 여성’, ‘20대 초반’ 같은 수준으로 접근하지 말고, 특정 상황에서 어떤 행동(구매결정)을 하게 되는 숨겨진 이유를 알아내라.
• The end goal is to identify the temporary situations that cause people to change and buy something.
• Remember that people experience situations, and those situations drive needs (jobs to be done).
• 문제상황은 니즈 이전에 발생한다. 갑자기 사람들이 아침에 일어나자마자 ‘나 살 빼야지’라는 말이 나오는 게 아니라 무슨 사건이 발생할 때(체중계에 올라가거나, 친구가 살쪘다고 할 때) 살 빼려는 니즈가 생긴다.
• 179cm의 미국 피닉스 주에 사는 여성은 물론 iPhone 구입할 수도 있을 것이다. 상관관계야 나오겠지. 하지만 179cm의 미국 피닉스 주에 사는 여성이라는 사실이 갑자기 아이폰 구매를 유발하지 않는다.

B2B도 똑같다.

• ‘인원수 50명에 업력 5년인 IT 회사’라는 곳에 갑자기 니즈가 솟아나는 게 아니라 어떤 회사가 임원이 바뀌는 과정에서 컨퍼런스룸을 새로 만들 니즈가 생겼거나, 쓰던 제품이 지원 중단되거나 할 때 니즈가 생기는 식이다.

가입인사 드립니다! 앱 하나를 만들고 있는데요

Q. 팀 이름과 만들고 있는 제품 이름이 무엇인가요? 제품을 한 문장으로 소개한다면?

Bind라는 이름의 Android와 iOS용 앱을 홀로 만들고 있었습니다. 나중에 보기 위한 웹 링크를 앱 안에 저장할 수 있고, 이 링크를 소비하는데에 도움되도록 미리 알림(Reminder) 기능을 제공합니다.

Q. 최근에 제품에 있었던 가장 큰 변화는 무엇이었나요?

앱 출시 자체가 가장 큰 일이었습니다. 출시 전후에 다양한 분들을 대상으로 이 제품이 풀고자 하는 문제에 관해 인터뷰를 진행하고 제품에 대한 의견을 수합했습니다.

Q. 요즘 제품 성장에 있어 가장 큰 고민은 무엇인가요?

이 제품의 타겟인, 소비는 못하고 쌓이기만 하는 링크 저장에 대한 문제를 가장 크게 느끼는 분들을 어디서 어떻게 찾을지가 가장 고민입니다. 수많은 인터뷰를 통해서 링크를 쌓기만 하고 소비는 못하고 계신 분들이 많다는 것은 발견했는데요, 이를 큰 문제로 느끼는 분들은 많이 없는 것 같았습니다. 이게 도대체 얼마나 큰 문제일지, 애초에 소비할 목적은 없고 그저 안전하게 링크 저장만 잘 되면 괜찮은 것인지, 그래도 누군가에겐 쌓이기만 하는 상황 자체가 정말 고통스럽진 않을지, 그런 사람들은 어디에 모여있고 어떻게 찾을 수 있을지… 좀 더 이런 상황을 큰 문제로 느끼는 분들을 다수 만날 수 있어야 더 좋은 해결책이 떠오를 것 같습니다. 하지만 시간은 한정적이기에 문제 자체를 피봇할 고민도 하고 있긴 합니다.

Q. '왜 안 쓸까 내 제품?'이라는 고민을 하는 분들께 도움될 수 있는 나만의 역량이나 경험이 있다면?

열심히 노력했지만 아무도 안 쓰게 된 제품이나 기능을 여럿 만들어봤던 것 같습니다. 쓸모 없는 개발을 줄여야 했고 치열하게 데이터를 봐야했는데, 이렇게 얻어 맞아 본 몇몇 경험이 누군가에겐 도움이 될지 모르겠습니다!

🖖

'열심히 잘 만들었는데 왜 아무도 안 쓰죠?'

얼마 전 인터넷에서 우연히 마주친 포스트가 있습니다.

'서비스를 런칭했는데 100명도 가입을 안 해요. 전 분명히 쓸모있는 걸 만들었고 심지어 무료로 풀었는데 사람들이 왜 관심이 없는 거죠? 제가 뭔가 잘못하고 있는 걸까요?'

*원문: Indie Hackers: Not able to get even 100 signups on my product even though it's valuable and free

저도 이런 고민을 자주 하는 입장에서 무슨 일인가 싶어 곧장 제목을 클릭해 들어갔는데요, 많은 사람들이 댓글을 통해 글쓴이에게 생각보다 자세한 피드백을 주고 있었습니다.

'무슨 근거로 쓸모 있는 걸 만들었다고 생각하신 거죠? 사람들이 가입을 안 한다는 건 애초에 쓸모 없는 걸 만들었다는 얘기일텐데요.'

'님이 어떤 의도를 담아 서비스를 만들었는지는 아무도 관심 없어요. 정말 가치있는 걸 만들었다고 생각한다면 오히려 먼저 유료로 팔아보시죠.'

'Reddit에 홍보할만한 채널들 다음처럼 추천드립니다.' (*Reddit: 미국의 주제 기반 소셜 커뮤니티)

'이런 서비스를 공짜로 제공한다니깐 오히려 신뢰가 안 가네요.'

'완성도 탓 할 때가 아닌 것 같아요. 제품이 정말 가치가 있다면 UI/UX, 가입 과정, 결제 허들, 리뷰 개수 같은 건 아무 상관 없어요.'

'이런 랜딩페이지에 신경 쓰지 말고 구체적인 사람에게 실제 가치를 한 번이라도 전달하는 걸 먼저해보는 건 어때요?'

만드는 행위가 자체가 좋거나 자기만의 신념 때문에 제품을 만드는 분도 있지만, 정말 문제를 겪는 누군가에게 꼭 필요한 해결책을 만들어서 감동을 전하고 싶은 분도 있습니다.

제품을 만들며 이미 좌절을 겪어 본 사람들, 한창 고민 중인 사람들이 모여 공감과 위로에 그치는 게 아니라 유용하고 과학적인 피드백과 자기만의 인사이트를 주고 받을 수 있는 공간을 같이 만들어볼까요?

👇 '왜 안 쓸까 내 제품' 클럽으로 초대합니다! 👇

왜 안 쓸까 내 제품 | Disquiet*

제품을 열심히 만들었는데 아무도 안 쓴다고요? 일어날 일이 일어났군요. 그렇다면 이 클럽에 들어 오셔야 합니다. 각자 만들고 있는 제품의 현재 상황을 공유하고 대책을 주고 받으며 좌절을 극복해봅시다.

https://disquiet.io/club/zero-user-product

https://disquiet.io/club/zero-user-product

'누구나 그럴싸한 계획을 가지고 있다. 쳐맞기 전까지는.' — Mike Tyson

글쓰기 혐오에서 벗어나다

글 같은 거 쓸 시간에 코드 한 줄이라도 더 짜는게 맞지라는 생각을 강하게 갖고 있었는데요, 요즘 무언가 함께 만들 분을 계속 찾아나서는 와중에 몇 가지 시행착오를 겪으며 이런 생각을 바꾸게 되었습니다.

팀원을 찾는 메이커라면 3가지 이유 때문에라도 글쓰기를 하는 게 효율적입니다. 다음 글을 통해 그 이유를 정리해보았습니다.

https://medium.com/@stargt/글쓰기-혐오에서-벗어나다-708bf1d0e689

하지만 한 번의 시도조차 도전하기 어려울 만큼 가진 것이 없다면 상대에게 근거 있는 신뢰를 주고, 자기 객관화를 지속하고, 열린 관점을 유지하기 위한 도구로 글쓰기만큼 가성비 좋은 것이 또 있을까? 홀로 도전하는 사람들에게 글쓰기는 ‘함께’가 되기 전에 거쳐야 할 관문일 수 있다. ― 내용 中