사이드 프로젝트를 계속 시작하지만 절대 출시하지 못할 때
주말 에너지를 사용자에게 전달되는 가치로 바꾸는 90일 실행 계획.
사이드 프로젝트를 시작하는 순간은 깔끔합니다.
아이디어가 분명합니다. 첫 버전이 가까워 보입니다. 스택도 재미있습니다. 주말에는 충분히 진전할 수 있을 것 같습니다.
그러다 프로젝트가 커집니다.
기능 하나가 세 개가 됩니다. 랜딩 페이지를 더 다듬어야 합니다. 온보딩이 아직 준비되지 않았습니다. analytics는 나중으로 미룹니다. 아이디어는 모양을 바꿉니다. 몇 주 뒤 repo는 있지만 아무도 쓰지 않습니다.
이것은 게으름이 아닙니다.
대부분의 사이드 프로젝트는 만든 사람이 신경 쓰지 않아서 실패하지 않습니다.
Shipping이 사라진 뒤에도 만들기가 계속 진전처럼 느껴지기 때문에 실패합니다.
사이드 프로젝트가 막히는 이유
사이드 프로젝트는 남은 에너지로 굴러가기 때문에 취약합니다.
일, 가족, 행정, 일상생활이 끝난 뒤 프로젝트는 남은 관심을 받습니다. 그래서 계획은 매우 명확해야 합니다.
하지만 대부분의 사이드 프로젝트 계획은 흐릿합니다:
- MVP 만들기,
- UI 정리하기,
- auth 추가하기,
- 콘텐츠 쓰기,
- 제품 개선하기,
- 곧 출시하기.
이것들은 주간 행동이 아닙니다.
안개입니다.
유용한 사이드 프로젝트 시스템은 네 가지를 보호해야 합니다:
- 작은 사용자 결과,
- 단단한 MVP 경계,
- 더 많은 polish 전의 실제 피드백,
- 매주 하나의 보이는 shipping 신호.
그것이 없으면 프로젝트는 사적인 만들기로 드리프트합니다.
미니 진단
사이드 프로젝트를 계속 시작하지만 출시하지 못한다면 어떤 gap이 루프를 깨는지 확인하세요.
1. 사용자 결과가 충분히 작지 않다
“크리에이터를 위한 앱 만들기”는 너무 넓습니다.
“한 크리에이터가 10분 안에 더 나은 sponsor reply 3개를 작성하게 돕기”는 테스트할 만큼 작습니다.
더 작은 버전은 덜 야심찬 것이 아닙니다. 더 출시 가능합니다.
물어보세요:
- 첫 실제 사용자는 누구인가요?
- 첫 버전이 그 사람이 어떤 일을 하도록 도와야 하나요?
- 한 세션 안에 느낄 수 있는 결과는 무엇인가요?
- 그 결과를 깨지 않고 제거할 수 있는 것은 무엇인가요?
사용자 결과가 흐릿하면 모든 기능이 필요해 보입니다.
2. MVP 경계가 계속 움직인다
Scope creep은 교묘합니다. 추가 기능마다 합리적으로 들리기 때문입니다.
프로젝트에는 설정 하나, dashboard 하나, onboarding 단계 하나, integration 하나가 “그냥 더” 필요해 보입니다.
하지만 MVP 경계는 프로젝트를 좋게 만들 모든 것의 목록이 아닙니다.
유용한 신호를 만들 수 있는 가장 작은 버전입니다.
사이드 프로젝트에는 이런 규칙이 필요합니다:
첫 사용자가 첫 결과에 도달하는 데 도움이 되지 않으면 기다린다.
이 규칙은 에너지가 optional work로 새는 것을 막습니다.
3. 피드백이 너무 늦게 온다
사적으로 만드는 일은 편합니다.
피드백은 덜 편합니다. 아이디어가 혼란스럽거나 불필요하거나 잘못된 사람을 향하고 있다는 것을 드러낼 수 있기 때문입니다.
하지만 늦은 피드백은 비쌉니다.
신호를 얻는 데 큰 출시가 필요한 것은 아닙니다. 몇 사람 앞에 놓을 만큼 구체적인 무언가가 필요합니다:
- 거친 데모,
- 클릭 가능한 flow,
- 하나의 약속을 담은 landing page,
- 짧은 Loom,
- workflow의 수동 버전,
- 사용하는 모습을 지켜볼 첫 사용자.
목표는 칭찬이 아닙니다.
목표는 한 달 더 만들기 전에 무엇이 바뀌어야 하는지 배우는 것입니다.
4. Distribution을 마지막 단계로 취급한다
많은 사이드 프로젝트는 출시 뒤에 사용자가 올 것처럼 만들어집니다.
그런 일은 드뭅니다.
Distribution은 프로젝트의 일부입니다. 프로젝트가 끝난 뒤의 축하가 아닙니다.
매주 하나의 보이는 distribution 행동이 있어야 합니다:
- 세 명의 구체적인 사람에게 보내기,
- 구체적인 데모 하나 올리기,
- 커뮤니티에 진짜 문제 질문하기,
- 짧은 use-case page 쓰기,
- 관심을 보인 사람에게 follow-up하기,
- 사용자에게 무엇이 막았는지 묻기.
아무도 프로젝트를 보지 않으면 프로젝트는 아무것도 가르쳐 주지 못합니다.
간단한 90일 사이드 프로젝트 실행 계획
첫 구조로 이것을 사용하세요.
결과
90일 안에 명확한 사용자 그룹이 하나의 유용한 결과를 얻도록 돕는 가장 작은 사이드 프로젝트 버전을 출시하고, 실제 피드백으로 다음에 무엇을 만들지 결정한다.
마일스톤 1: 첫 결과를 고정한다
첫 결과를 한 문장으로 쓰세요:
- 사용자,
- 문제,
- 결과,
- 절약되는 시간이나 노력,
- 결과가 일어났다는 proof.
예:
솔로 founder가 지저분한 launch notes를 15분 안에 한 페이지짜리 주간 행동 계획으로 바꾸도록 돕는다.
이제 그 결과를 돕지 않는 모든 것을 제거하세요.
마일스톤 2: 보이는 버전 하나를 출시한다
보이는 버전은 완성될 필요가 없습니다.
신호를 만들 만큼 사용할 수 있으면 됩니다:
- 누군가 시도합니다,
- 누군가 답장합니다,
- 누군가 무엇이 헷갈렸는지 말합니다,
- 누군가 빠진 조각을 묻습니다,
- 누군가 사용하지 않을 이유를 말합니다.
그 신호는 또 하나의 사적인 기능보다 더 가치 있습니다.
마일스톤 3: 피드백 루프를 만든다
매주 같은 루프를 실행하세요:
- 작은 개선 하나를 출시한다,
- 실제 사람들 앞에 놓는다,
- 피드백을 기록한다,
- 무엇을 자르고, 유지하고, 바꿀지 결정한다,
- 다음 행동 하나를 고른다.
프로젝트는 루프가 살아 있기 때문에 살아남습니다.
주간 실행 루프
이 루프를 매주 한 번 실행하세요:
- 이번 주의 가장 작은 사용자 결과를 고른다.
- 그 결과에 기여하지 않는 기능이나 작업 하나를 자른다.
- 작더라도 보이는 artifact 하나를 출시한다.
- 세 명의 구체적인 사람에게 피드백을 요청한다.
- 아이디어 backlog가 아니라 신호에서 다음 행동을 결정한다.
이것이 “사이드 프로젝트를 하고 있다”와 “사이드 프로젝트를 출시하고 있다”의 차이입니다.
계획으로 바꾸기
사이드 프로젝트가 매번 새로운 설렘으로 다시 시작하지만 사용자에게 전달된 가치가 없다면, backlog 정리로 시작하지 마세요.
고통에서 시작하세요:
사이드 프로젝트를 계속 시작하지만 절대 출시하지 못한다.
그다음 이것을 90일 실행 시스템으로 바꾸세요: 하나의 사용자 결과, 단단한 MVP 경계, 주간 shipping 신호, 피드백 루프, 다음 행동.
90일 실행 계획 생성기를 사용해 첫 버전을 만드세요. 미리보기가 유용하면 살아 있는 X18 미션으로 저장해 주말 이후에도 프로젝트가 계속 움직이게 하세요.
