IT 프로덕트 메이커를 위한 SNS, 디스콰이엇에 올라온 글을 직접 읽고 엄선해 공유드립니다.
AI 제품을 만들고 있다면?
👉 '10X AI CLUB'에 가입하고 메이커들과 온라인/오프라인 네트워킹하기
IT 프로덕트 인사이트를 나누고 싶다면?
👉 '프로덕트 분석가 클럽'에 가입하고 얼라어답터들의 프로덕트 추천받기
유료 고객 100명 모았습니다
월 3,900원 아이디어 구독 서비스인 <아이디어광>을 운영한지 10개월.. 드디어 유료 구독자 100명을 넘겼습니다. (투자 받을 수 있나요..?) 그 기념으로 하나씩 회포를 풀어보고자 합니다.
일반적인 프론트엔드 프로젝트에서 오버엔지니어링 하지 않기
오늘 소개해드리는 이 글은 우리가 일상적으로 만드는 프론트엔드 프로젝트가 어떤 걸 갖추면 좋은지 이야기합니다. 반대로 어떤 요소들이 오버엔지니어링을 발생시키는지 말해줍니다.
이 글이 좋았던 이유는 여기에서 말하는 대부분의 것들은 생각보다 일정 규모 이상의 조직에서 경험하게 된다는 것입니다. 즉, 제가 경험하고 들어본 대부분의 작은 조직에선 이 글에서 말하는 '갖추면 좋은' 구성도 고려 대상이 아닙니다. 그들 역시 회사를 먹여살리는 일상적인 규모의 프론트엔드 프로젝트를 운영함에도 그렇습니다.
그렇기 때문에 이 글이 눈에 들어왔습니다. 프로젝트를 구성할 때 참고하면 도움이 되지 않을까 합니다. 이 글에서 추천한 몇몇 섹션에 대해 제 생각을 공유하는 걸로 마무리 해보겠습니다 :)
실패한 스타트업이 남긴 교훈
실패를 경험한 것은 약간 부끄러운 이야기일 수도 있지만, 때로는 실패가 재기의 기회가 되기도 한다. 벤처캐피털에 합류하기 전에 사업을 한 경험이 있다. 동대문에서 옷을 떼서 팔아본 적도 있고, 앱을 만들어 배포해본 적도 있다. 결국 다 잘 되지 않았다. 지금 돌아보면 사업의 기본기가 전혀 없었던 만큼 맨바닥에 헤딩을 했다.
그때는 고객 인터뷰도, OMTM 설정도, POC도 할 줄 몰랐다. 그저 닥치는대로 하다보니 PMF를 찾지 못했다. 고객의 페인 포인트(pain point)도 확실하지 않은 상황에서 MVP도 아닌 프로덕트 그 자체를 만들다가, ‘사람 문제’라는 외부적인 요인으로 더이상 해당 스타트업을 지속하는 것이 의미가 없어지는 지경이 되었다.
댓글로 콘텐츠가 어땠는지 남겨주세요! 벨로그 독자분들이 더 좋아하실만한 콘텐츠로 찾아뵙겠습니다.
행복한 연말 되세요 :) 🎄
