SaaS의 2번째 S는 Service이다

최근 Lenny의 뉴스레터 중, Figma의 고객 집착에 대한 글을 읽었습니다.

1. 고객 지원은 모두의 일이다

• Customer Support is everyone’s job은 핵심 문화이다.

  1. 고객의 문제 이해

  2. 즉각적인 지원을 통한 문제 해결

  3. (필요시) 제품 전체 업데이트

• 사용자들은 개발자들이 몇 줄의 코드를 얼마나 빠르게 작성하는지 판단하지 않는다. 그들은 단지, 중요한 일을 얼마나 빨리 대응하는지 판단할 뿐이다.

2. Software as a service

• 디자인 툴은 사용자의 행복과 만족에 집중해야 한다.

  Figma를 호텔이나 레스토랑이라고 상상하고, 사용자를 손님으로 상상했다. SaaS(Software as a Service) 즉 Figma는 서비스를 제공하는 업체이다. Service-Oriented 마인드 셋을 바탕으로 “사용자의 문제”를 해결하는 데 도움을 주는 도구로 제품을 바라보았다.

3. 느낌의 중요성

• 디자이너들에게 디자인 도구의 "느낌"은 중요하다. 이것은 본능적으로 느낄 수 있고 강제로 만들 수 없다.

• Figma는 출시 시 핵심적인 기능만을 잘 디자인하여 제공하였다. 적지만 신뢰할 수 있는 기능이 훨씬 중요하다.

• 제품의 "느낌"을 결정할 때, 사용자가 제품을 얼마나 자주 사용하는지 고려해야 한다. 일반적으로 빈도가 높은 제품은 사용자의 기대를 충족시키는 것이 중요하다.

• 제품의 느낌에 대한 확신이 없다면, 제품 사용 경험이 어떠한지, 그리고 만족하지 않는다면 그 이유를 직접 물어보는 것이 중요하다.

Thoughts

이전 B2B SaaS 제품을 제공하던 직장에서, 매일 전화를 걸어 불만사항을 전달하던 고객이 있었습니다.

그 고객의 요구사항은 다른 고객들에게 영향을 끼쳤으며, 한 편으로는 고객이 우리 원칙을 조금은 따라주기를 바랬습니다.

하지만 돌이켜보면 이는 완전히 잘못된 생각이었습니다.

Software as a SERVICE 를 제공하는 입장으로서, 고객이 제시하는 해결책을 모두 제공하지 못하더라도, 문제를 정확하게 해결해주는 것이 필요했습니다.

서비스 시장은 냉정합니다.

불만을 표출하는 고객은, 다른 대안으로 넘어가는 최후의 선택 이전이라는 의미일 것입니다.

SaaS라는 단어를 입에 달고 살았지만, 정작 Service란 무엇일지 고민해볼 수 있는 좋은 글이었습니다.

밑바닥부터 제품만들기 #2 - 아이디어와 팀

안녕하세요

저는 현재 밑바닥부터 제품을 만들고 있습니다.

팀원을 구하는 것과 아이디어를 정하는 것 중 어느 것이 먼저라고 생각하시나요?

이제까지는 아이디어가 먼저라고 생각했습니다.

하지만 여러 제품의 성공사례를 보면서, 아이디어는 성공에 큰 영향이 없다는 것을 깨달았습니다.

그래서 제 머릿속 수 많은 아이디어들을 뒤로하고 동료를 먼저 구하기로 마음 먹었습니다.

어차피 초기 아이디어는 뒤집히고, 그 순간 팀원들과 다시 아이디어를 찾아야하기 때문이죠.

YC의 Jared Friedman은 아이디어를 찾는 7가지 방법을 제시했습니다.(중요도 순)

1. 팀이 잘하는 것을 하는 것(가장 중요)

2. 스스로 처한 문제를 푸는 것

3. 개인적으로 존재했으면 하는 것을 생각해보는 것(가장 위험)

4. 최근에 세상에서 달라진 것을 찾는 것

5. 성공한 기업들의 변형 찾기

6. 사람들에게 문제가 무엇인지 물어보기

7. 망한 것 같은 큰 시장을 찾기

그래서 좋은 아이디어를 통해 팀원을 구하는 것은 그만 두기로 했습니다.

그 대신 아이디어를 찾는 방법을 정리하여 제시하려고 합니다.

빨리 좋은 팀원을 한 분이라도 만나, 제품이야기를 신나게 나누고, 검증하고 싶습니다.

관심있으시거나 좋은 메이커 분을 알고계시다면 알려주세요!

팀에 관심 없어도 커피챗은 언제나 환영입니다!

개발지식 없이 GPT로 개발하기

안녕하세요

현재 제품을 만들고 있는 유정현이라고 합니다.

제품을 만드는 사람으로서, 노코드로 할 수 있는 것들이 많아 개발은 고민하지 않았는데요.

최근들어 제가 원하는 MVP를 만들기 위해 최소한의 것은 할 줄 알아야겠다는 필요성을 느꼈습니다.

그래서 Chat GPT를 업그레이드 하고, flutter 개발을 노코드로 해보았습니다.

일단 무엇을 만들지 고민에 시간을 쏟기 싫어, 당장 생각났던 영어단어 외우기 앱을 만들어보았습니다.

개발지식이 전혀 없어도 GPT로 노코드 MVP정도는 만들 수 있다고 느껴 짧은 느낀점 전달드립니다.

코드를 짤 필요는 없다.

제가 원했던 기능의 90%가 완성된 지금, 아직도 저는 Flutter의 문법을 전혀알지 못합니다.(당연히 코드 한 줄도 쓰지 않았습니다.)

제가 한 것은 오직

프롬프트로 원하는 것(에러메시지) 입력 -> 응답된 코드 Copy&Paste -> 컴파일 -> 동작 확인

의 반복이었습니다.

GPT4와 3.5는 매우 다르다.

GPT4의 대답에는 관리 영역까지 신경쓰는 것 같았습니다.

"이 코드는 보안상 취약점이 있으니 절대 public에서 사용하지 마세요"등의 메시지를 주더라구요

그래서 Gpt3.5에 같은 질문을 해보았고, 4가 말한 임시방편 해결책을 '제시'만 했습니다.

구글링해보니, 그 방법대로 짜면 서버비 폭탄을 맞을 수도 있었습니다.

제일 어려운 것은 환경 세팅이다.

Flutter Firebase Setting 이 세글자가 들어간 수 십개의 유튜브 영상을 시청하였고, 한국어 블로그는 거의 다 봤으며, 영어 블로그도 수 십개 본 것 같습니다.

기본 개발지식이 없으면, 주변 지인한테 환경세팅 정도는 도움을 요청하면 편합니다.

기능을 한 번에 하나씩 요청해야한다.

chat gpt 4는 3시간에 25개 밖에 못 날리기에 여러 가지의 요구사항을 한번에 전달해보았는데요.

간단한건 잘 처리했지만, 코드가 길어지니 한 번에 한 개씩 하는 것이 훨씬 효율적이더라구요.

Github으로 무조건 버전관리를 해야한다.

코드를 읽지 못하는 까막눈이다보니 ctrl+z는 굉장히 한계가 있습니다.

어떤 코드가 돌아갔던 코드인지 판단을 못하기 때문이죠.

그래서 Github으로 한 가지 기능이 에러없이 완성된 직후 push를 해주었습니다.

만약 다음 기능에서 에러가 터진다면, github에서 최근 Push된 것을 다시 복붙하면 되거든요.

(Git은 어려워서 Github이 더 좋은 것 같아요)

연속된 응답이 유리하다.

Chat을 바꾸면 계속 이전 코드를 기억하지 못하고 이상한 대답을 주기도 합니다.

새로운 챗으로 바꾸지 말고 진행하면 좋습니다.

단, GPT4와 3를 돌아가면서 해야할 때는, 코드와 파일명을 한 번 모두 입력하고 시작하면 많이 도움이 됩니다.

진짜 빠르다.

환경세팅 2시간, Firebase 연동 4시간이 걸렸지만, 코드를 만든 것은 1시간도 걸리지 않았습니다.

객관적으로는 형편 없을지 몰라도, 제 기준으로는 0 to 1을 해낸 것과 다름없거든요.

(그 것도 하루만에)

MVP를 만들어야할 때, 노코드 GPT 코딩 한 번 시도해보시는건 어떨까요? ㅎㅎ

밑바닥부터 제품만들기 #1 - 회고와 반성

안녕하세요.

밑바닥부터 제품을 만들고 있는 유정현이라고 합니다.

현재 저는 제품과 팀 심지어 아이디어도 없는 상태입니다.

5년 이상 제품을 만들기 위해 노력하고 있지만, 아직 원하는 결과를 얻지 못하였습니다.

지난날 배운 것과 메이커들의 생생한 경험들, 성공한 창업자의 인사이트 등을 바탕으로 제품을 다시 만들고 있습니다.

1.팀의 중심에는 아이템이 있었다.

아이템을 가장 중요하게 생각했습니다. 팀을 빌딩 할 때도 아이디어로 설득해야 했습니다. 결국 아이템의 매력이 사라지거나, 성공에 대한 확신이 사라질 때마다 팀은 해체되었습니다. 

→ 팀의 중심에 비전을 둔다.

"제품은 팀의 부속물이다" 라는 말을 좋아합니다. 좋은 제품을 만드는 것은 좋은 팀이 만들어내는 것이라 믿습니다. 만든 것을 모두 포기하고 피벗을 하거나, 매일같이 논쟁을 하더라도 좋은 팀은 견뎌낼 수 있다고 믿습니다.

이를 가능하게 하는 것은 팀의 비전이라고 생각합니다. 비전에 입각한 의사결정은 모두에게 합리적으로 다가올 것입니다. 따라서, 비전을 정의하고, 그 비전을 이루기 위한 다양한 목표들을 설정할 것입니다.

2.PMF을 소홀히 여겼다.

아이템을 중요하게 생각했지만, 역설적으로 PMF은 가볍게 생각했습니다. 그래서 MVP를 만들고 사용자의 반응을 살펴야 했습니다. 중간에 발견된 문제나 의심을 삼키고 MVP 완성이 목표가 되었습니다. 또 높은 확률로 MVP가 시장이 원하는 것이 아니었습니다.

→ PMF을 찾고 개발에 들어간다.

개발은 PMF을 어느 정도 찾은 이후에 시작할 것입니다. 사용자가 원하는지 확인한 뒤에 개발을 시작해도 늦지 않을 것입니다. 오히려 PMF이 없는 상태에서 만들기 시작하는 것이 더 위험할지도 모릅니다.

3.좋은 의사결정을 하지 못하였다.

의사결정을 위한 기준이 없었습니다. '기준이 없다'는 것은 의미 없는 의사결정에 시간을 쏟고, 모든 의견을 최대한 수용해야 한다는 뜻입니다. 결국 의사결정 힘들고 두려운 일이 되었으며, 마지막에는 목소리 큰 사람의 의견을 듣게 되었습니다.

→ 팀원 모두가 동의하는 비전과 목표를 정한다.

비전은 팀의 구심점입니다. 명확한 비전과 적절한 목표를 선정하여 의사결정의 어려움을 줄이려고 합니다. 이 구심점이 명확할수록 의사결정은 빠르고 좋은 결과를 낼 것이라고 믿습니다.

회고와 반성을 바탕으로 다음 할 일을 고민해 보았습니다. 도언님이 PMC에 올려주신 핸드북을 많이 참고하려고 합니다.

비전 정의하기

개인적으로 내고 싶은 임팩트는 과연 무엇일지 고민하고 정의합니다.

비전에 맞는 가설 여러 개 만들기

1pager로 여러 가설을 만들면서 시장을 파악하려고 합니다.

비전에 맞는 팀원 구하기

비전에 맞는 팀원을 신중히 구하기 시작합니다.

PMF 사례 정리하기

PMF의 성공사례를 정리하고, 현재 상황과 1 Pager로 작성한 가설을 기반으로 PMF 사례를 찾을 것입니다. 

지난 글 읽기

1. 밑바닥부터 제품만들기 #1 회고와 반성

2. 밑바닥부터 제품만들기 #2 어떤 종류의 제품을 만들까?

긴 글 읽어주셔서 감사합니다:)