스타트업에서 어떻게 IT 프로덕트를 만드는가
많은 난관이 있다.
사람, 자본, 시간, 기술력
너무 당연한 소리겠지만 MVP가 나와야한다.
MVP는 그냥 대표가 들고다니면서 시연하는 용이면 그냥 대표가 노코드툴이다 그림판으로 만들면 되고,
내가 말하는 MVP는 변경가능하도록 개발 스택과 낮은 개발 러닝커브와 유지보수가 가능한 코드지만 낮은 비용으로 유지보수가 가능한 MVP를 만드는 것이다.
예를 들어 typescript 를 사용하지않는다.
1. 있는 자원을 사용한다. (현재 있는 자원을 사용한다.) 캐릭터를 좋아하는 디자이너가 있으면 그냥 활용한다. 프로덕트가 시장반응이 있으면 그리고 우리가 고객 여정 파이프라인을 잘 설정했다면 새로운 디자이너가 합류해 디자인 고도화 프로젝트를 띄울 수 있다.
2. 있는 기술을 사용한다. : 개발자가 Spring 을 잘하는데 '우린 스타트업' 이니 새로운 기술로 해보자 ! (ㄴㄴ) 새로운 기술은 미안한데 캐시카우를 만들고 나서나 할 수 있는거임.
3. 최소 기능을 만든다. : 내가 말하는 최소기능은 책에서 말하는 최소 기능이 아닌. 개발 구조상 최소기능이다. 개발자 입장에서 아' 그건 나중에 추가할 수 있어요! 라고 하는거 빼고 만드는 거다.
예를 들어 로그인이면 카카오 로그인 빼고 다 제거한다. (개발자 입장에서 다른 로그인은 나중에 추가할 수 있게 인증인가를 고려해서 oauth 구성할 거다)
예를 들어 마이페이지에는 로그아웃만 있으면된다. 기타 정보 는 다 나중에 추가할 수 있다.
리더는 (PM이든 PO든) 부가 기능과 핵심기능이 뭔지 생각을 해야한다. 차별성이라고 부가 기능을 무조건 넣을려고 하면 안된다. 그렇기 전에 팀은 터진다. 사업 기회인 전쟁터는 다른 맵으로 변한다. 투자시장은 얼어붙는다. 사람들은 싸운다. 직원들은 의심한다. 멘탈은 터진다. 시간은 가고 사람들은 늙는다. 돈은 소비된다.
최근 유행하는 말은 기능이든 브랜딩이든 색깔이든 뾰족해야한다고 말한다. 하지만 IT사업에서는 명확하고 굳세야한다. 일단 살아남아야 깍아서 뾰족하게 만들 수 있다.
오래된 생각이다.
4. 최대한 SaaS 서비스 및 분별력 잇는 라이브러리를 사용해야한다.
5. 감각적인 디자인과 예술적인 디자인은 사실 뒤로 미뤄야한다. 일단 사람들은 익숙한 것을 원하고 앱과 웹을 통한 상품이 바라보는 시장은 익숙한 것에 반응한다. (걍 경험)
6. 속도가 제일 중요하다. 속도는 기술력이 아니다. 팀원의 경험에서 나온다.
'10개 해야 하나터짐' 이라는 마인드 . 성숙하지 않는 팀일 수록 자신의 프로덕트가 시장을
한번에 잡을거라는 생각을 한다.
하지만 성숙하고 경험있는 팀은 지구력을 내재해놓고 간다.
7. 일단 마일스톤을 계속 찍는 식으로 가야한다. 허접해도 마일스톤(시각화된 프로덕트)를 보고 상상을 할 수 있어야한다.
8. 첫번째 마일스톤을 찍었으면, 이제 프로덕트에 상상하면서 고객에 집중해야한다.
왜냐면 첫번째 마일스톤 이후 고객이 없으면 그냥 쓰레기다. 고객이든 걍 관심가질 만할 사람을 100명을 인터뷰해야한다.
리더는 PM 프로젝트 매니징을 하는게 아니다.
시나리오를 모으고, 디자인(설계)를 해야한다. 프로덕트 매니져란 말은 국내에서 애매해서 PO를 쓰는것 같은데
PO도 필요없다. '내가 아닌' 고객들 입장에서 가상의 페르소나를 세우고 (진짜여도 됨) 계속해서
시나리오를 종합하고 ,------> 필요한 기능명세를 만들고 =------> 디자인설계 (걍 노트에 그리면됨) 이거 무한 반복해야한다.
9. 디자이너는 내가 한 디자인 설계(기획)기반으로 시각화를 입힌다.
10. 개발자에게 시각화된 아이템을 보여주고 만들어달라고 한다.
기획과 명세 없다고 개발자가 이야기할거다. 근데 그건 걍 커뮤니케이션으로 풀어야한다.
왜냐면 이제 실제하는 프로덕트가 있으니깐 기획 문서만드는게 바보같은 짓이다.
이미 시나리오 종합 ---> 기능명세---> 다지인 설계를 통해서 나온 시각화 피그마기 때문에 그건
걍 커뮤니케이션으로 풀고, 직접 앱이튼 웹이든 만지작 거리면서 나아갸야한다.
11. 사실상 제일 어려운것은 첫 MVP다. 그것만 되면 사이클은 돈다. (서투르지만0
12. 이제 백엔드 개발자가 의문을 제시할거다. 하지만, 백엔드 개발자는 디자이너와 얼라인된
경험있는 클라이언트 + 디자이너)의 요청을 듣고 스스로 기능명세를 잡고 개발해야한다. .
결론: 최소최소최소 기능을 만든다. 하나씩 붙인다.
사이클은 리더 --> 디자이너 --> 클라이언트개발자 ---> 백개발자
여기에 부가적인PM PO 공유문서, 원격큰무를 통한 커뮤니케이션, wiki 이런건 헛소다.
이런것들은 미안한데 상품이 있고 캐시카우가 있고, 고객이 있으면서
각 파트별로 4명이상 넘어간다음에 생각할 문제다.
그리고 파트에 4명이상 넘어간다 해도 코어인재가 없으면 다 물거품이다.
경험없는 놈들이. 새로운 툴. 새로운 기술. 새로운 업무방식. 새로운 스택. 새로운 AI Generated 기술을 이야기한다.
중요한거 사람간의 협동이다. 협동없이 껍데기 대화가 잘된다고 해도 실패한다.
방어적으로 개발 전략을 짜야한다
1~3년차 개발자가 할수있어요 언제까지 할께요! 하는 말은 믿지말고
4~5년차 개발자의 말도 최대한 방어적으로 들어야한다
물론 스타 개발자는 예외
브랜드 전략 cx전략 마케팅 전략은 저 초초초방어적인 개발전략 베이스로 공격을 펼칠수있다.
뮌헨에서 괜히 노이어, 키미히, 김민재 를 쓰는게 아니다. 수비가 되야 공격된다. 개발전략은 방어적이게 가야한다.
Business/Product (Dev+Design)
