YC 코파운더인 제시카 리빙스턴의 글을 읽고

제시카 리빙스턴은 YC의 공동 창업자이자 폴 그레이엄의 아내로 유명하다. 근데 폴 그레이엄이나 YC의 인지도가 워낙 높아서, YC는 알아도 제시카에 대해선 모르는 사람이 많다. 나도 원래 그랬는데, 우연히 6년 전 글인 Grow the Puzzle Around You를 읽고 제시카에 대해서 조금이나마 알게 됐다. 인상 깊은 내용이 많았다.

좋은 걸 만드는 사람들의 기질

제시카는 지시받는 것을 무척이나 싫어하고, 다른 사람들에게 상당히 직설적으로 소통하는 편이라고 한다. 그리고 남편인 폴 그레이엄과 매일 우리 주변에 놓인 문제들에 대해서 얘기하고 해결책을 찾아나가는 것이 숨 쉬듯 자연스러우며, 특히 폴 그레이엄의 특징 중 하나를 "지금 당신이 해야 할 일은 ~이다" 라는 말버릇이라고도 했다. 또한 YC를 만들 때는 처음부터 높은 기준을 세팅해 좋은 사람을 모으고 문화를 만들었다. 결과적으로 YC는 전 세계 최고의 액셀러레이터고 YC Alumni는 메이커 네트워크 중 단연코 Top이다. YC는 지금도 훌륭한 제품들을 계속해서 발굴해내고 있다. YC 자체가 최고의 프로덕트다. 어떻게 이런 걸 만들 수 있었을까? 내 생각엔 아래와 같은 기질들이 있는 것 같다.

• 매우 능동적이다. 남이 시키는 것을 그냥 하지 않으며, 항상 의문을 가진다. 왜 그래야하지? 왜 그게 당연한거지? 그걸 하면 무엇이 나아지는거지?

• 솔직하다. 좋게좋게 말하느니 아무 말도 안하는게 차라리 낫고, 정말 상대방을 위한다면 최대한 솔직하고 분명하게 말해준다. 이런 사람들이 결국 진실에 가까워진다.

• 문제 위주로 사고한다. 우리 주변에 어떤 문제들이 있는지, 그 문제들이 얼마나 중요한지, 무슨 문제를 먼저 풀어야하는지, 어떻게 해결할 수 있는지 등.

• 환경을 만든다. 능동적이며 문제 위주로 사고할 줄 아는 똑똑한 사람들로 주변을 채우고 문화를 만들어버린다.

• 실행한다. 생각하는 것에서 그치지 않고, 그걸 실행으로 옮긴다.

남이 말하는 대로, 소셜 미디어에 보이는 대로, 다른 회사들이 한다고, 그냥 곧이 곧대로 받아들이고 줏대 없이 사고하면 좋은 것을 만들기 어렵다. 독립적인 사고를 할 줄 알아 자기만의 철학이 있고, 문제를 해결하기 위해선 정말 무엇을 해야하는지 알기위해 노력하는 사람들만이 의미있고 가치있는 것을 만들 수 있다. 남을 보고 따라하지 말자.

이제는 온라인 상에 너무나도 많은 정보와 좋은 인사이트들이 많고, 다양한 방법을 통해 자신의 네트워크를 0에서 100으로 만들 수 있으며, 아이디어를 실현할 수 있는 도구들도 많다. 이럴 때 일수록 절제해서 정보를 섭취하고, 천천히 독립적으로 생각하고, 어떤 문제가 가장 우선순위가 높은지 고민하고, 결정했으면 최고의 퀄리티로 실행해서 문제를 해결하는데 집중해야한다.

그외 읽으면서 남긴 메모들

1. 제시카는 폴과 다른 사람들이 중요한 것에 집중할 수 있도록, 그 외 일들을 책임지고 완성도 있게 해내려고 노력했다. 내가 처음 디스콰이엇에 들어오면서 가졌던 마음가짐과 동일하다.

2. 남을 보고 따라하려고 하지 말고, 자기 자신이 되자. 내가 가장 잘할 수 있고, 가장 남을 잘 도울 수 있는 것을 더 살리자.

3. 정말 좋아하거나 호기심 있는 걸 하자. 안그러면 질려서 오래 못하고 포기한다.

4. 고객이 하는 말 아니면 듣지마라

5. 초기 팀원

   • 커다란 질문에 동의하는가? -> 미션, 비전, 중요하게 생각하는 가치

   • 작은 질문들엔 존중하는가? -> 상대방의 강점, 전문성, 경험

6. 거절 어차피 엄청 많이 당할거니까 신경쓰지말고 계속 하기

7. 작게 시작해야 더 빠르게 움직이고 실행할 수 있음

8. 자격증, 학력, 이전 직장, 이런 거 필요없고 좋은 제품 하나만 만들어봤으면 된다

원문

소프트웨어 시장에서 Taste의 중요도

점점 소프트웨어를 만들고 운영하는 비용이 낮아지고 민주화 되고 있다.

Chat GPT가 나온 후 내가 한번도 접해보지 못한 개발 언어로 어디까지 개발 가능한지 테스트해보고 싶어 나에게는 완전 생소한 Swift를 활용한 간단한 앱을 만들어봤다. Swift의 문법, coding convention에 대한 리서치 없이 바로 만드는 것을 시도해봤는데 mock data를 만들어 mapping하면서 내가 원하는 화면을 구현하는데 큰 무리가 없었다. 코드를 완벽히 이해하지는 못하지만 대략적인 맥락을 이해하면서 개발이 가능했다.

개발 비용 뿐만 아니라 운영 비용도 낮아지고 있다. 서버를 직접 구축할 필요가 없게 된 클라우드를 시작으로 자동화 툴들, 핵심 비즈니스 외의 것들을 관리해주는 다양한 SaaS 들이 나오면서 운영 비용은 지속적으로 낮아지고 있었다. 여기에 더해 요 몇주 동안 화재가 된 AutoGPT는 운영비를 더더욱 획기적으로 낮춰버리는 촉매재가 될 것처럼 보인다.

이런 상황에 대해서 다양한 내러티브가 나오고 있다. 일자리를 잃는 것 아닌가 하는 회의적인 반응부터 앞으로 생산성이 높아지면서 좀 더 많은 사람들이 쉽게 높은 수준의 소프트웨어를 만들 수 있을 것 같다는 기대감도 있다. 내가 개인적으로 흥미를 갖는 내러티브는 앞으로 소프트웨어 개발 비용이 점점 줄어드는 것이 사람들이 소프트웨어를 선택하는데 미치는 영향이다.

나는 사람들이 점점 인간다운 면들을 중요하게 여길 것이라 생각한다. 내가 관심갖는 인간다운 면은 3가지다.

1. 창작욕

2. 유대감 형성

3. 아름다움 추구

창작욕

디스콰이엇에서 계속 강조하는 창작에 대한 열망은 가장 인간다운 면이다.

지난 주 스티브잡스가 실제 한 인터뷰와 이메일들을 모아 출간한 책인 “Make something wonderful”[1]을 읽었다. 읽으면서 정말 멋진 것을 만들고자 하는 욕구가 들었다. 그러다 문뜩 이런 느낌에 대한 호기심이 생겼다. 스티브잡스에 대한 이야기를 접하게 되었을때 이런 창작 욕구가 드는 것은 나만 그런 것이 아닌 보편적으로 관찰되는 반응이다. 왜 그런걸까?

그 답은 이 책의 제목 그리고 도입부에 있다.

There’s lots of ways to be, as a person. And some people express their deep appreciation in different ways. But one of the ways that I believe people express their appreciation to the rest of humanity is to make something wonderful and put it out there.

And you never meet the people. You never shake their hands. You never hear their story or tell yours. But somehow, in the act of making something with a great deal of care and love, something’s transmitted there. And it’s a way of expressing to the rest of our species our deep appreciation. So we need to be true to who we are and remember what’s really important to us. -Steve Jobs

우리가 갖고 있는 가장 인간적인 욕망 중 하나가 나의 인생이 무의미하게 소비되는 것이 아닌 어떤 방식으로든 세상의 발전에 기여하고 있는 욕망이다. 이런 욕망을 충족하는 방법 중 하나가 멋진 것을 창작해서 세상에 내놓는 것이다. 이런 욕망으로 만들어진 것들을 접해보면 창작자의 깊은 고민과 사랑이 전달된다.

스티브잡스의 이야기나 애플의 제품들, 픽사 영화들을 보면 사람들에게 감동을 전달하려는 깊은 애착이 느껴진다. 이런 애착이 느껴질때 우리 또한 멋진 것을 만들어 세상에 기여하고 싶다는 욕구가 생기는 것 같다.

유대감 형성

이런 애착을 감지할때 우리는 유대감을 형성하게 된다.

멋진 제품을 보면 우리는 호기심을 느낀다. 이런 호기심을 해소하기 위해 그 제품의 창작 스토리를 찾게 되고 창작 과정에서 창작자가 어떤 고민을 했는지 파고들게 된다. 스토리를 읽어나가면서 호기심은 경외심으로 바뀌고 유대감이 형성된다.

우리가 브랜딩이 잘되어있다고 여기는 회사들을 보면 제품과 회사를 만들어가는 과정에서의 고민들이 사람들에게 잘 전달되어 있고 사람들이 그 브랜드에 감정적인 유대감을 느낀다.

나는 종종 주변 사람들에게 요즘 가장 잘만들었다고 생각하는 제품이 무엇인지 물어본다. 최근 Linear라는 제품이 정말 좋다는 이야기를 많이 들어 디스콰이엇에서도 도입하게 되었다. 처음 접했을때는 기존 프로젝트 관리툴 대비 심플하고 보통 팀들이 겪는 제품 개발 과정을 잘 고려했다는 생각을 했다. 이후 어떻게 이런 제품을 만들 수 있었는지 호기심이 생겨 그들의 미션, 제품 철학, 시장을 바라보는 관점[2] 등을 읽게 되었고 그러면서 점점 이들에 대한 애착이 생겼다.

창작자와 소비자 간의 유대도 있지만 이를 같이 만들어가는 사람들과의 유대도 있다.

내가 개발에 기여한 제품이 시장에서 널리 사용되는 것에 대한 로망을 처음으로 해소해본 것은 첫 회사에 다니면서였다. 그때 Fitbit 디자인에 참여를 했었고 Fitbit은 전세계 사람들로부터 사용 되었다. 많은 사람들이 사용하는 제품 개발에 참여한 것에 큰 보람을 느꼈지만 이보다 더 큰 충족감을 예상치 못한 곳에서 느꼈다. 같이 디자인하는 팀원들과 매일 밤늦게까지 디자인과 기술에 대해 이야기를 하고 Fitbit을 디자인하면서 급속도로 친해지는 경험을 했다. 이때 일이 일같이 느껴지지 않았고 그냥 디자인과 기술에 열정이 많은 사람들끼리 취미 활동하는 것처럼 느껴졌다.

이런 깨달음을 얻고 나서 디스콰이엇에서 팀을 만들어나갈때도 나를 포함한 팀원들이 이렇게 공동의 미션을 향해 나아가는 과정에서 서로의 열정을 교류하고 유대감을 쌓을 수 있는 환경을 만들고자 노력하고 있다.

아름다움 추구

강한 애착이 담겨 있는 것들을 보면 미적 아름다움을 중요시한다. 하지만 이런 미적 아름다움을 중요시하는 것이 모든 사람들에게 항상 가치있게 여겨지지는 않는다. 이는 사회가 얼마나 물질적으로 풍요로운지와 관련있다. 물질적 풍요로움이 증가할수록 사람들은 단순히 배를 채우는 것, 몸을 따뜻하게 하는 것, 그리고 잘 곳을 마련하는 것을 넘어 소속감, 인정, 자아 실현 등을 중요시하며 미적 아름다움을 추구하는 것은 자아 실현과 밀접하게 관련되어 있다.

소프트웨어의 생산비용이 낮아지면서 소프트웨어 시장의 물질적 풍요도가 높아지고 있다. 이에 따라 자연스럽게 소비자들은 소프트웨어를 선택할때 미적 아름다움을 추구하기 시작하고 있다. 여기서 미적 아름다움은 단순히 보이기에 이쁜 것을 이야기하지 않는다. 그보다는 기능적 문제를 해결해주는 것을 넘어서 즐거움과 감동을 느낄 수 있게 해주는 요소들이 담긴 것을 이야기한다.

이미 이런 현상은 B2B SaaS의 흐름을 보면 보여진다. 예전에 B2B 제품을 생각하면 미적 아름다움은 제품이 시장으로부터 선택을 받는데 영향이 없었다. 하지만 점점 많은 사람들이 일상의 많은 영역에서 소프트웨어를 경험하면서 소프트웨어의 기준이 높아지기 시작했고 이런 높은 기준이 B2B로도 넘어오기 시작했다. 그러다보니 앞서 말한 확고한 제품 철학과 스토리텔링 역량으로 무장한 Linear같은 제품이 이미 포화된 프로젝트 매니징 소프트웨어 시장에서 영향을 미치기 시작했다.

소프트웨어의 생산성이 높아지면서 생기게 되는 소프트웨어 시장의 풍요는 사람들이 소프트웨어를 선택할때 미적 아름다움을 점점 중요시하도록 만들 것이다.

결론

몇년 전까지만 해도 이런 내용들이 지나치게 이상주의적이라 생각했다. 하지만 인류의 역사를 보면 우리는 계속 이상을 쫓아오고 있다. 평등, 평화, 민주화를 계속 쫓아오고 있고 그 과정에서 전쟁을 일으키기도 하고 기술적 발전을 이루어오고 있다. 최근에는 소프트웨어 개발의 민주화가 이루어지고 있다.

이런 급진적인 변화로 기대감이 있기도 하지만 한편으로 피로하게 느껴지기도 한다. 개인적으로 피로함이 높아지면서 진정성이 느껴지는 것들을 계속 찾게 되는 것 같다. 그래서 원래는 관심이 없던 에세이를 읽어보기도 하고 Linear 같이 진정성을 갖고 제품을 만들어가는 메이커들의 이야기를 찾아서 읽어보기도 한다. 그러면 어느 정도 피로함이 상쇄되는 느낌이 든다.

이또한 내가 본질적으로 갖고 있는 인간다움을 느끼고 싶은 욕구에서 나오는 것 같다.

참고 자료

[1] 스티브잡스의 인터뷰와 이메일들을 모아서 만든 책: https://book.stevejobsarchive.com/

[2] Linear의 제품 철학을 읽고 적은 메이커로그: https://disquiet.io/@hpark0011/makerlog/7611

상위 1% PM

최근 지인이 PM의 역할에 대해서 물어봐 이야기를 나눴다.

나는 PM이 잘해야 되는 것을 딱 한문장으로 정리하면 프로덕트가 성공하기 위해 팀원들이 각자의 영역에서 최고의 의사결정을 내는 것에만 집중할 수 있도록 환경을 조성하고 관리하는 사람이라 생각한다. 결정의 구체적 범위는 팀의 미션, 문화, 단계, 전략, 로드맵 등에 따라 다를 수 있지만 일반화시켜 이야기하자면 개발자는 최고의 개발 결정을 내리는 것에만 집중하게 해야되고 디자이너는 최고의 해결책을 내리는 것에만 집중할 수 있도록 해야된다. 이를 목표로 일을 하면 나머지는 다 따라온다.

이를 달성하기 위해서 PM이 갖춰야 될 역량이 여러개 있는데 이를 잘 정리해 놓은 글이 있어 공유한다.(번역하는 과정에서 저의 생각이 약간 첨가 되었을 수도 있으니 원본을 보고 싶은 분들은 아래에서 원본 링크를 클릭해보세요.)

1. 생각을 크게 해야 된다 - 눈앞에 보이는 작은 기회가 아닌 더 큰 기회를 볼 수 있어야 된다.

2. 탁월한 커뮤니케이션 역량을 지녀야 된다 - 데이터가 있을때는 데이터를 잘 사용하고 그렇지 않을때는 사람들이 갖고 있는 편견, 신념, 동기 등을 이해하고 이를 활용해 필요한 자원을 확보할 줄 안다.

3. 단순해야 된다 - 20%만의 노력으로 80%의 가치를 얻을 수 있어야 된다. 디자이너나 개발자들이 과도한 디자인 혹은 개발을 하려 할때 단순화 시킬 줄 알아야 된다.

4. 우선순위를 잘 세운다 - 단기적인 성과를 위한 투자, 장기적인 성과를 위한 투자, 비즈니스를 성장시키기 위한 투자, 비즈니스를 더 탄탄하게 하기 위한 투자 등의 우선순위를 잘 구분하여 순서를 잘 만든다.

5. 예측과 측정을 잘한다 - 이전 경험 혹은 벤치마크들을 활용해 프로젝트로부터 얻을 수 있는 가치를 미리 어느정도 예측을 하고 이를 잘 측정할 수 있어야 된다. 프로젝트 시작 전 KPI를 잘 설정하고 측정 방은을 잘 설계해야 된다.

6. 실행력이 좋아야 된다 - 기간에 맞춰 유저들에게 기능을 전달하기까지 어떤 문제든 해결할 수 있어야 된다. 채용을 하든, 직접 개발에 관여를 하건, 세일즈를 하건.

7. 기술적 비용에 대한 이해가 있어야 된다 - PM이 CS전공자일 필요는 없지만 어느 정도의 기술적 이해력을 갖고 특정 기능 개발이 어느 정도의 기술적 복잡성을 지니고 있는지를 파악하고 우선 순위를 세울 수 있어야 된다.

8. 좋은 디자인에 대한 이해가 있어야 된다 - 좋은 디자인을 직접 만들 역량을 갖출 필요는 없지만 좋은 디자인과 안 좋은 디자인을 선별할 수 있는 역량을 갖춰야 된다.

9. 글을 잘써야 된다 - 간단 명료하게 글을 쓸 줄 안다. 글을 길게 쓸수록 글의 전달력이 떨어지는 것을 이해한다. 기능 개발에서는 적절한 단어를 활용할 줄 알아야 된다.

10. 팀의 신뢰를 얻을 수 있어야 된다 - 사람들에 대한 이해를 바탕으로 신뢰를 얻을 수 있어야 된다. 개개인 마다 신뢰를 얻는 방법이 다를 수 있으며 이를 이해하고 다른 접근 방법을 써가며 신뢰를 얻어내야 된다.

11. 데이터를 파고들 줄 알아야 된다 - 최적의 결정을 내리기 위해 어떤 데이터가 필요한지 명확히하고 이 데이터를 얻어낼 수 있어야 된다.

12. 틀린 것이 있을때 집어낼 수 있어야 된다 - 더 높은 결정권자의 압박에도 불구하고 틀린 것이 있다면 틀린 것을 집어내고 데이터와 논리를 바탕으로 자신의 주장을 할 수 있어야 된다.

13. 변화에 빨리 적응할 수 있어야 된다 - 리더쉽이나 회사의 전체적인 방향 혹은 전략의 변경에 크게 동요하지 않고 빨리 적응해서 최대의 임팩트를 낼 수 있어야 된다.

14. 임팩트를 내는 것에 대한 갈망이 있어야 된다 - 진급과 같이 보여지는 것에 신경쓰기 보다는 하루에 얼마나 임팩트를 낼 수 있는지가 동기가 되어야 된다.

여기에 나와있는 모든 것을 잘하기는 거의 불가능하다. 이 글의 저자는 최소 요건으로 커뮤니케이션 역량, 우선순위를 가르는 역량, 그리고 실행력을 가져야 된다고 하며 개인적으로 이에 동의한다.

원문:

페이스북 출신 PM이 만든 데이터 중심적이지 않은 브라우저

최근 급성장중인 인터넷 브라우저 Arc를 사용해봤는데 사용자가 브라우저를 사용하는 과정에서 느끼는 감정들에 대해서 정말 신경을 많이 썼다는 생각이 들었습니다. 개인적으로 온보딩 과정이 즐거웠고 보통 다른 프로덕트들은 사용법을 읽고 배우는 과정이 귀찮은데 Arc는 이마저 호기심이 들게하고 재미있다는 느낌이 들었습니다.

Arc를 만드는 회사인 The Browser Company의 창업자 Josh Miller가 나오는 팟캐스트를 들었는데 굉장히 다른 관점으로 제품을 만들어나가고 있었습니다.

제가 Arc를 사용하면서 느낀 즐거운 감정들은 이들이 가장 집중하는 점이였습니다. 이들은 지표를 최적화 시키는 것이 아닌 감정에 최적화시키는 제품 개발 문화를 만들었습니다. 흥미로운 것은 Josh Miller는 Facebook에서 PM을 했었는데 이때 지표 중심의 제품 개발에 한계를 많이 느꼈다고 합니다. 지표나 그래프는 사람들의 확실한 행동과 같이 확실히 숫자로 표현 가능한 수치를 달성하는데는 굉장히 효율적이지만 사람들이 프로덕트나 브랜드에 긍정적인 감정을 느끼는지는 알 수 없습니다. 하지만 디즈니, 나이키, 애플과 같은 가장 사랑받는 브래드들을 생각해보면 제품을 구매하고 사용했을때 다른 제품에서는 느낄 수 없는 즐거움이 있습니다. Josh Miller가 Facebook에 조인했을때 한창 Snapchat이 뜨고 있었고 Snapchat이 단순히 얼마나 많은 사람들이 Snap버튼을 누르는지 신경쓰는 것이 아닌 사람들이 프로덕트를 사용하면서 느끼는 감정을 잘 파고들었다는 생각을 하게 되었고 The Browser Company에도 이런 관점을 반영했다고 합니다.

보통 제품을 한문장으로 쉽게 설명할 수 있어야 된다고 하는데요, Josh Miller는 Arc Browser를 간단하게 설명하는데 어려움을 느끼고 있다고 하는 점도 흥미로웠습니다. 아직 런칭한지 얼마 안되었지만 현재 Arc Browser는 숨은 기능이 굉장히 많은데요, 스스로 생각하기에도 이점이 문제인 것 같다고 합니다. 그래서 지금 잘 성장하고 있으니 비대해진 기능들을 깎아내리는 작업을 할거라고 합니다.

저도 최근에 이와 같은 제품 개발 방식이 괜찮을 것 같다는 생각을 하고 있습니다. 완전 데이터 중심 프로덕트와 지난번 Linear글 소개하면서 이야기한 Opinionated 프로덕트의 스펙트럼이 있다고 한다면 어느 지점이 조화로운지 고민하고 있습니다.

매력적인 사람에 대해서 생각해봤습니다. 자신의 색깔 없이 쉽게 트렌드에 휩쓸리는 사람은 매력없습니다. 반대로 너무 자기 고집이 쌔고 세상을 편협하게 바라보는 사람들도 매력 없습니다. 제게 매력적인 사람은 독립적인 사고를 할 수 있으면서도 편협하지 않고 다양한 관점에 대해서 열린 사람입니다. 자신만의 세상을 바라보는 관점을 발전시키지만 이게 틀릴 수 있다는 것을 항상 염두하면서 다양한 관점을 접해보고 이를 바탕으로 좀 더 진리에 다가가려 합니다.

제가 생각하는 가장 이상적인 프로덕트 개발도 이와 비슷한 것 같습니다. 프로덕트가 던지는 확고한 철학이 있지만 그 철학이 절대적이라고 생각하지 않고 다양한 실험을 해보면서 배워나갑니다. 디스콰이엇의 경우 저는 사람들이 지식 교류하고, 영감을 나누고, 문제를 해결하면서 유대 관계를 쌓는 것이 우리 사회에 필요한 이상적인 소셜네트워킹 경험이라는 철학을 갖고 있습니다. 하지만 이를 달성하는 방법에는 열린 마음으로 다양한 실험을 해보면서 배우고자 합니다. 배우는 과정에서 제품이 비대해질 수 있습니다. 그런 경우 최적의 방법을 제외한 나머지는 다시 깎아내리는 작업을 해야 된다고 생각하고 있습니다.

팟캐스트:

의견이 강한 제품 vs 커스터마이징이 가능한 제품

제가 최근 본 프로덕트 중 가장 잘 만들었다고 생각이 드는 툴은 Linear입니다. Linear는 개발자들의 Issue관리 툴입니다. Issue가 생소하신 분들은 기존의 Jira나 Asana와 경쟁하는 프로젝트 관리 툴이라고 생각하면 됩니다. Linear를 리서치하던 중 재미있는 인터뷰 아티클이 있어 제 생각과 함께 공유합니다.

Linear의 창업자 Karri는 Airbnb와 Coinbase에서 디자이너로 일을 했었고 이전에 창업을 하면서 YC 프로그램도 참여했습니다. 다양한 조직에서 제품 개발을 하면서 지라와 같은 프로젝트 매니징 툴을 사용했지만 그 경험이 고통스러웠고 이 경험을 개선하기 위해 Linear를 창업하게 되었다고 합니다.

Linear는 현재 많은 제품 조직에서 채용하고 있는 Agile 프로세스를 바꾸려 하고 있습니다. 그 근간에는 Agile로는 좋은 퀄리티의 제품이 나오지 않는다는 생각이 바탕 되어 있습니다. 이 기사에 보면 Karri는 핀란드 사람으로 핀란드의 디자인 철학에 영향을 많이 받아 이런 철학을 소프트웨어에 적용하고 싶어 합니다.

핀란드는 비싸지 않으면서도 단순하고 기능적인 디자인 철학을 갖고 있는 것으로 유명합니다. Karri는 못생기게 만들어진 제품들이 많은 것이 처음에 의아했다고 합니다. 하지만 다양한 제품 개발에 관여를 해보면서 그 이유가 제품 개발 과정이 잘못되어 있어서 못생긴 제품이 많아졌다고 생각하게 되었습니다.

이런 철학은 Linear 제품에 정말 잘 녹아 있습니다. Jira를 보면 정말 많은 기능들이 있습니다. 이렇게 기능이 많아진 이유는 제품 조직마다 다 제품 개발 프로세스가 조금씩 다르고 이런 모든 엣지 케이스들을 다 만족시키려하다보니 복잡해졌습니다. Linear는 반대의 접근을 합니다. 어차피 세상에 완벽한 제품 개발 프로세스는 없으니 이를 다 만족시키려하면서 제품을 복잡하게 만들기 보다는 Linear가 생각하는 최고의 제품 개발 프로세스를 정의하고 이에 적합하게 개발합니다.

이렇게 의견이 강한 것들과 개인에 맞게 커스터마이징을 많이할 수 있도록 하는 것의 철학적 싸움은 다른 분야에서도 관찰되어져 왔습니다. 가장 고전적인 예시로는 Mac과 PC, iOS와 안드로이드가 있고 개발 언어에서는 Ruby on Rails가 의견이 확고한 것으로 알려져 있습니다.

의견이 강한 제품들은 제품을 구매하거나 설치한 후 바로 본래의 가치를 느끼기 까지의 마찰을 최소화시킵니다. (이를 보통 Plug and play라고 합니다.) 반면 커스터마이징을 할 수 있는 제품들은 세팅하는데 시간이 많이 걸리고 이 과정이 복잡합니다.

이렇게 의견이 강한 제품을 만들려면 어느 정도 유저들의 피드백을 선별해서 들을 수 있어야 됩니다. 혹은 대다수의 유저들이나 업계 전문가들이 주는 피드백과 반대되는 결정을 내리는 경우도 있습니다.

저는 개인적으로 유저 피드백을 받으면서 빠르게 다양한 실험을 하는 것과 확고한 철학을 바탕으로 의견이 강한 제품을 만드는 것의 최적의 지점이 있다고 생각합니다. 여기서 중요한 점은 확고한 철학이 있느냐인 것 같습니다. 그래서 실험을 하되 실험이 그 철학에 맞지 않으면 아무리 다수가 원한다고 해도 과감히 포기할 수 있어야 되는 것 같습니다.

Linear 인터뷰 아티클:

Full Build Startup

어제 YC의 MVP에 대해서 글을 공유했는데요,

오늘은 이 반대 관점을 공유해봅니다. Equals라는 회사의 글입니다.

-

본문 요약

Equals는 Customer Service 툴로 유명한 Intercom의 멤버들이 나와서 만든 Spread Sheet 툴이다. Google Sheet, Excel 등과 경쟁하는 제품을 만들고 있다.

이들의 인사이트는 단순하다. 스프레드 시트 사용을 대체하는 다양한 아날리틱 툴, 대시보드, 혹은 생산성 툴들이 나오고 있지만 우리는 결국 다시 스프레드 시트로 돌아간다. 스프레드 시트 사용에서 가장 불편한 점은 데이터를 입력하는 것이다. 이를 클릭 한번으로 자동화 시켜준다는 것이 이들의 핵심 인사이트이다.

이들은 MVP를 만드는 것을 거부했다. 글을 읽어보면 이들의 논리는 이렇다.

스프레드 시트 사용은 우리가 너무 오랫동안 해왔기 때문에 사용성이 조금만 안 좋아도 금방 불편하게 느껴진다. 기존의 스프레드 시트들이 제공하는 것에 더해서 빠른 속도, 팀을 위한 동적 에디팅, 그리고 다른 앱과의 데이터 연동이 가능해야 된다고 생각했고 따라서 MVP를 만들기를 거부했다.

다만 시장에 너무 새로운 아이디어를 한번에 소개하면 안된다. 신제품은 사실상 새로운 아이디어를 베팅하는 것인데 새로운 아이디어가 너무 많으면 리스크가 너무 커진다. 따라서 정말 중요한 핵심 아이디어 한가지 이외에는 기존 에 사람들이 이미 익숙한 것을 개발한다.

Equals의 경우 데이터를 연동하는 것이 하나의 큰 새로운 아이디어이다.

그 외 이 글에서 소개하는 Full build startup의 예시들:

• 테슬라
• 펠레톤
• 피그마

느낀점

이 글의 제목 때문에 자칫 핵심이 가려지는 위험성이 있다는 생각이 든다. 이 글에서 가장 중요한 점은 핵심 인사이트를 기반한 큰 아이디어 한개를 테스트하는 것에만 집중하는 것이다.

나도 개인적으로 디스콰이엇 관련 데이터를 다 스프레드 시트에 옮겨서 보는데 처음에는 이를 직접 내가 다 아날리틱 툴에서 스프레드 시트 화면으로 옮겼다. 이것이 항상 큰 페인 포인트였고 그래서 Equals의 데이터 연동을 쉽게 해주는 Spread Sheet라는 Value Proposition에 흥미가 가서 사용해봤다. 당연 내가 평소에 사용하는 Google Spread Sheet 대비 Spread Sheet 기능은 많이 부족하고 불편하지만 데이터 연동만 잘되면 다른 것의 불편을 감수하고라서도 쓸 생각이였다. 하지만 데이터 연동이 엄청 편하다는 느낌을 못받아 그냥 스크립트를 작성해 자동화를 시켜나가고 있다.

최근 이렇게 다양한 사례들을 보는데 글을 읽다보면 특정 방법론이 중요하지 않다는 생각이 든다. 그보다는 회사의 철학과 그에 맞는 형태를 갖추는 것이 더 중요한 것 같다.

본문글:

The Full Build Startup

Nearly all startup advice is for MVP driven startups. But for a certain type of company you *need* to start with more.

https://wraptext.equals.app/the-full-build-startup/

MVP 개발

제품 개발에 도움되는 내용이라 공유합니다.

1) 빠르게 런칭한 후 수정하기

많이 하는 실수 중 하나는 수십개에서 수백개의 설문조사와 인터뷰를 하는데 시간을 낭비하는 것이다. 제품이 유저나 고객의 문제를 해결해주는지는 실제 제품을 사용해본 유저로부터만 배울 수 있다. 따라서 최대한 빠르게 런칭한 후 제품을 사용하는 사용자로부터 배워야 된다.

2) 제품에 대한 첫경험이 안 좋으면 다시 안 돌아올거라는 두려움 떨치기

제품을 빨리 런칭하지 않는 가장 큰 이유는 첫인상이 좋지 않아 한번 돌아선 고객이 다시 돌아오지 않을거라는 두려움 때문이다. 보통 스타트업의 제품을 사용하는 고객들은 얼리 어답터들이다. 이들은 다양한 제품을 사용해보는 것을 좋아하며 첫경험이 좋지 않더라도 다시 연락하면 돌아온다.

반면 첫경험이 좋지 않아서 다시 돌아오지 않는 고객들은 얼리 어답터가 아니다. 애초에 스타트업이 이들을 타깃하는 것은 좋은 전략이 아니다. 이런 사람들 때문에 빨리 런칭하는 것을 두려워하면 안된다.

3) 가짜 스티브 잡스

스티브 잡스는 천재적인 직관으로 오랫동안 좋은 제품을 갈고 닦아서 완벽할때 런칭했다고 사람들이 생각한다. 하지만 이는 착각이다. 첫 아이폰을 생각해보면 카메라도 없었고 앱을 설치할 수도 없었다. 하지만 이후 매년 반복해서 더 개선된 제품을 내놨고 지금의 완벽한 아이폰이 탄생되었다. 스티브 잡스도 계속 런칭하고 개선한다.

4) Software MVP

소프트웨어 MVP는 아무리 많아도 월 단위를 넘기면 안되고 왠만하면 주 단위에서 개발을 할 수 있어야 된다. 그러려면 최소한의 기능만 있어야 되고 아주 소수의 유저들을 타깃해야 된다.

사례 1) Airbnb

• 결제 기능이 없었다.

• 지도뷰가 없었다.

• 호스트하려면 에어침대가 있어야 되었다.

• 컨퍼런스 참가자들만 타깃했다.

사례 2) Twitch

• 채널이 1개 밖에 없었다.

• 영상의 화질이 안좋았다.

• 게임 스트리밍이 없었다.

• 스티리밍 비용이 높았다.

사례 3) Stripe

• 작은 은행들과의 계약 밖에 없었다.

• 고객들과 은행과의 계약을 중개하기 위해서 창업자들이 직접 종이 문서 작업을 했다.

• 고객들로부터 신용카드 결제를 받는 것만 되기만 하면 되는 스타트업들을 타깃했다.

5) 머리에 불붙은 고객들만 타깃해야 된다.

지금 당신의 머리에 불이 붙었다. 바로 옆에 누군가 벽돌을 판매하고 잇다. 그럼 당신이 물과 호스를 판매하는 사람을 기다릴까? 아니다. 누군가 벽돌을 판매하면 그 벽돌을 구매해서 머리카락을 부벼서 불을 끌것이다. 이렇게 머리에 불붙은 고객들만 타깃하고 나머지는 일단 넘겨야 된다.

원본자료:

공지 확인했어요!

디스콰이엇의 유저인터뷰 사례 공유가 무엇인가요?