UIpac

Build-Measure-Learn, 작게 돌려보기

린 스타트업에서 가장 유명한 개념이 Build-Measure-Learn, 즉 만들고, 재고, 배우는 순환입니다.책으로 읽을 때는 당연한 이야기처럼 들리는데, 막상 제 아이디어에 적용하려고 하면 "그래서 일주일 동안 뭘 하라는 거지?" 싶었어요.그래서 이 루프를 1~2주 단위로 잘게 쪼개서 실제로 돌려본다면 어떻게 하는지, 가정 예시와 함께 정리해봤습니다. 이 순환은 Build에서 시작하는 것처럼 보이지만, 책에서도 계획은 거꾸로 세우라는 취지로 설명한다고 이해했습니다.먼저 배우고 싶은 것(Learn)을 정하고, 그걸 확인하려면 무엇을 재야 하는지(Measure) 정한 다음, 마지막으로 그걸 재기 위해 최소한 무엇을 만들면 되는지(Build)를 정하는 식입니다.저는 이 순서가 중요하다고 느꼈어요.만들고 나..

법인과 개인사업자, 창업 형태 고르기 전에 확인할 것

창업을 준비하다 보면 어느 순간 "개인사업자로 시작할까, 법인으로 할까" 하는 질문이 꼭 나옵니다.저도 아직 어느 쪽도 정하지 않았고, 그래서 정리부터 해보려고 이 글을 씁니다.먼저 말씀드리면 저는 세무나 법률 전문가가 아니고, 아래 내용은 일반적으로 알려진 차이를 공부하며 정리한 것입니다.세부 요건과 세율, 지원 조건은 자주 바뀌기 때문에, 실제로 결정하실 때는 국세청이나 정부 지원사업 공고 같은 공식 안내와 전문가 상담을 꼭 확인하셔야 해요. 사업을 시작하는 시점이 되어서야 고민하면 시간에 쫓겨서 주변 말만 듣고 정하게 되는 경우가 많다고 해요.그래서 아직 시작 전인 지금, 어떤 질문을 해야 하는지부터 정리해두면 나중에 상담을 받을 때도 더 구체적으로 물어볼 수 있을 것 같았습니다.정답을 찾는 글이 ..

공동창업자와 역할 나누기, 팀 빌딩에서 정리한 기준

창업을 준비하면서 가장 자주 읽게 되는 주제 중 하나가 "누구와 함께할 것인가"였어요.아이템이나 시장은 공부하면 어느 정도 감이 오는데, 사람 문제는 책을 읽어도 사례를 읽어도 정답이 없다는 느낌이 들었습니다.그래서 이번 글은 제가 실제로 팀을 꾸렸다는 이야기가 아니라, 읽은 책과 사례에서 정리한 기준을 제 상황에 빗대어본 기록입니다. 초기 팀이 흔들리는 이유를 다룬 글이나 인터뷰를 보면, 기술이나 시장 때문이 아니라 사람 사이의 문제가 이유로 꼽히는 경우가 많았습니다.역할이 겹치거나, 서로 기대한 책임이 달랐거나, 힘들 때 의견이 갈리는 식이죠.물론 이건 읽은 이야기들에서 받은 인상이고, 통계로 확인한 건 아닙니다.저는 기획을 해온 사람이라서, 혼자서는 만들 수 없는 부분이 분명히 있습니다.그래서 누군..

기능 우선순위 프레임워크 비교, 1인 프로젝트에 ICE·RICE·Kano 적용해보기

기능 우선순위를 정하는 방법은 예전부터 많이 읽어왔는데, 막상 혼자 작은 서비스를 만들어보려니 어디에 어떻게 써야 할지 감이 오지 않았어요.읽을 때는 다 이해한 것 같은데, 내 기능 목록 앞에 앉으면 결국 "이것도 필요할 것 같고 저것도 필요할 것 같고"로 끝나더라고요.그래서 이번에는 대표적인 세 가지 방법(ICE, RICE, Kano)을 같은 기능 목록에 하나씩 적용해보고, 어떤 차이가 나는지 정리해봤습니다. 예시로 쓸 서비스는 실제로 만들고 있는 것이 아니라, 연습을 위해 가정한 것입니다.동네 독서모임 운영자가 모임 일정을 정할 때 단체 대화방에서 날짜를 일일이 묻는 게 번거롭다고 가정해볼게요.그래서 일정 후보를 올리면 참석자들이 투표하고, 가장 많이 가능한 날짜가 자동으로 정리되는 작은 웹서비스를 ..

IR 덱 구성, 투자자가 먼저 보는 장표

사업계획서가 "내 계획을 자세히 설명하는 문서"라면, IR 덱은 "짧은 시간에 핵심만 전달하는 발표 자료"에 가깝습니다.쉬는 동안 투자와 IR에 관한 책과 글, 공개된 사례를 읽으면서 덱의 구성을 정리해봤습니다.제가 투자를 받아본 것은 아니고, 읽고 정리하고 연습해본 내용이라는 점을 먼저 밝혀둡니다.그래도 기획자 입장에서 "슬라이드를 이런 순서로 놓는 이유"를 이해하는 과정이 꽤 재미있었어요. 자료를 보면 대체로 비슷한 흐름이 반복됩니다.제가 정리한 순서는 다음과 같습니다.표지: 서비스 이름과 한 줄 소개.문제: 누가 어떤 불편을 겪는가.해결: 우리 방식은 무엇이 다른가.제품: 실제 화면이나 사용 흐름.시장: 얼마나 큰 기회인가.비즈니스 모델: 어떻게 돈을 버는가.고객 반응: 지금까지 확인한 신호.경쟁과..

사업계획서 쓰기 - 문장보다 구조가 먼저

사업계획서라고 하면 왠지 거창한 문서가 떠오르는데, 막상 써보면 "내 생각을 남에게 설명하는 문서"라는 점에서 기획서와 닮아 있었습니다.쉬는 동안 지원사업 공고나 양식을 읽어보고, 연습 삼아 가상의 아이템으로 계획서를 써보는 과정을 거쳤어요.그때 가장 크게 배운 것은 문장을 다듬기 전에 구조를 먼저 잡아야 한다는 점이었습니다.오늘은 제가 정리한 구조와, 쓰면서 자주 했던 실수를 적어봅니다. 처음에는 첫 문단부터 멋지게 쓰려고 했습니다.그런데 문장을 다듬다 보면 어느새 같은 이야기를 반복하거나, 정작 중요한 내용이 빠져 있더라고요.구조를 먼저 잡고 칸마다 한두 줄 메모를 채워두면, 그다음에는 문장으로 풀기만 하면 됩니다.저는 글을 쓰기 전에 A4 한 장에 다섯 칸을 그립니다.문제, 해결, 시장, 모델, 실..

노코드 툴로 MVP 프로토타입 만들어보기

MVP 범위를 줄이고 나면 다음 고민은 "그럼 이걸 뭘로 만들지"입니다.저는 개발을 직업으로 하는 사람이 아니라서, 아이디어를 직접 손에 잡히는 형태로 만들어보려면 노코드 도구가 가장 현실적인 선택지로 보였어요.쉬는 동안 몇 가지 종류의 도구로 작은 프로토타입을 직접 만들어봤고, 그 과정에서 느낀 점을 정리합니다.특정 제품을 추천하는 글은 아니고, 도구의 종류와 고르는 기준에 대한 기록입니다. 처음에는 도구 이름을 비교하느라 시간을 많이 썼는데, 나중에 보니 이름보다 종류가 중요했습니다.제가 이해한 대로는 크게 세 갈래입니다. 첫째는 페이지 빌더형입니다.블록을 끌어다 놓아 소개 페이지나 신청 페이지를 만드는 도구입니다.고객이 처음 보는 화면을 빨리 만들 수 있고, 수요를 확인하는 용도로 좋습니다.둘째는 ..

MVP 범위 자르기 - 기능을 어디까지 빼야 하나

MVP(Minimum Viable Product)라는 말은 창업 책을 읽으면 어디서나 나옵니다.그런데 막상 내 아이디어에 적용하려고 하면, "최소"가 어디까지인지가 가장 어려웠어요.기획자로 일할 때 범위를 줄이는 일을 자주 해봤다고 생각했는데, 내 아이디어 앞에서는 전혀 다른 문제가 되더라고요.기능 하나하나가 다 소중해 보이니까요.이번 글에서는 범위를 자르는 순서와, 제가 여러 번 빠졌던 함정을 적어봅니다. 기능 목록을 쓰기 전에 먼저 하는 일이 있습니다.이 서비스가 고객에게 주는 핵심 가치를 한 문장으로 쓰는 것입니다.예를 들어 소규모 업장용 예약 서비스를 가정해볼게요."전화나 메신저로 받던 예약을 놓치지 않고 한곳에서 확인할 수 있다."이 정도가 한 문장의 예입니다.이 문장에는 "놓치지 않는다"와 "..

초기 서비스 가격, 어떻게 정해야 할까

비즈니스 모델 캔버스를 그리다 보면 수익원 칸 옆에 꼭 "얼마?"라는 질문이 따라붙습니다.기능은 이리저리 바꿀 수 있는데, 가격은 한 번 정해서 공개하면 바꾸기가 훨씬 조심스러워요.그래서 가격 정하는 방법을 책과 글, 그리고 제가 직접 해본 연습을 섞어 정리했습니다.정답을 찾았다기보다는 "이런 순서로 생각하면 덜 헤맨다"에 가까운 기록입니다. 가격을 정하는 방식은 크게 세 가지로 나눌 수 있었습니다. 첫째는 원가 기반입니다.들어가는 비용에 이익을 더해 가격을 정하는 방식입니다.계산은 명확한데, 고객이 느끼는 가치와는 상관이 없다는 점이 약점이에요.비용이 적게 드는 소프트웨어는 원가로 계산하면 터무니없이 싸게 나오기도 합니다.둘째는 경쟁 기반입니다.비슷한 서비스들이 받는 가격을 참고해서 그 근처로 정하는 ..

비즈니스 모델 캔버스로 수익 구조 그려보기

린 캔버스로 문제와 해결책을 정리하고 나니, 그다음에 막히는 질문이 있었습니다."그래서 이걸로 어떻게 돈을 버는가"였어요.기획자로 일할 때는 기능과 사용자 경험에 집중했지, 수익 구조까지 끝까지 그려볼 일은 많지 않았습니다.그래서 비즈니스 모델 캔버스를 다시 펼쳐놓고, 가정의 예시로 한 장을 채워보는 연습을 했습니다.이번 글은 그 정리입니다. 비즈니스 모델 캔버스는 한 장에 사업의 구조를 아홉 칸으로 나눠 그리는 도구입니다.왼쪽은 "어떻게 만들 것인가", 오른쪽은 "누구에게 어떻게 줄 것인가", 아래쪽은 "돈이 들어오고 나가는 구조"로 읽으면 편했어요.고객 세그먼트는 누구를 위한 것인가입니다.가치 제안은 그 고객의 어떤 문제를 어떻게 풀어주는가입니다.채널은 고객에게 어떻게 닿고 전달하는가입니다.고객 관계..

경쟁사 분석 템플릿 만들기

아이템 후보가 두세 개로 좁혀지면 꼭 하게 되는 일이 경쟁사 조사입니다.저도 처음에는 검색해서 눈에 띄는 서비스를 열어보고, 메모장에 느낌을 적는 식으로 했어요.그런데 후보가 바뀔 때마다 보는 항목이 달라져서, 나중에 비교하려고 하면 항목이 서로 맞지 않더라고요.그래서 쉬는 동안 정리해온 방식을 한 번 템플릿으로 고정해두기로 했습니다.오늘은 그 템플릿과, 쓰면서 알게 된 점을 기록해봅니다. 경쟁사 분석에서 제일 흔한 실수는 보이는 것만 적는 일인 것 같아요.화면이 예쁜지, 기능이 많은지는 눈에 잘 들어오니까 자꾸 그쪽으로 적게 됩니다.반면 가격 정책이나 고객이 어떤 경로로 들어오는지는 일부러 찾아야 보여서 빠지기 쉽습니다.항목을 미리 정해두면 "이 칸이 비어 있네, 더 찾아봐야겠다" 하는 신호가 생깁니다..

쉰 지 반년, 지금까지 정리한 것들

회사를 잠시 쉬기 시작한 지 어느새 다섯 달이 훌쩍 지났습니다.처음 계획을 세울 때 정한 대로 한 달에 한 번 점검을 하고 있는데, 이번에는 반년에 가까운 시점이라 조금 더 길게 돌아보기로 했어요.주간 기록을 처음부터 다시 읽어 보니, 기억하던 것과 실제로 한 일이 꽤 달랐습니다.잘했다고 생각한 것은 별것 아니었고, 대충 넘겼다고 생각한 것이 의외로 쌓여 있기도 했어요.그 차이를 포함해서 중간 점검을 적어 둡니다. 가장 확실하게 한 건 기록입니다.주간 기록은 몇 주 빠졌지만 대체로 이어 갔고, 글로 남긴 것도 생각보다 많아졌어요.불편함 노트, 아이템 후보 정리, 시장 규모 연습, 인터뷰 정리처럼 파일이 쌓이는 걸 보면 시간이 그냥 흘러간 건 아니구나 싶습니다.아이템 후보를 좁히는 작업도 진전이 있었습니다..