스타트업 제품 개발 계획 수립 가이드
2022/10/18⏱ 3mins -
김민성 (AI Biz)
-
제품 개발을 앞두고 계신 분
제품 개발 계획 수립 과정이 궁금하신 분
스타트업에서 일하시는 분
-
초기 제품 개발 계획 수립이 어려운 이유를 알아보고, 효과적으로 제품 개발 계획을 수립할 때 필요한 요소와 과정을 살펴봅니다.
-
✔️ 초기 제품 개발 계획 수립이 어려운 이유
✔️ 제품 개발 계획 수립 프로세스
제품을 개발한다는 것은 무에서 유를 창조해내는 멋진 일이자, 많은 사람들의 노력이 필요한 어려운 일입니다. 이 콘텐츠를 통해서는 AI 스타트업의 사업 개발팀에서 몸소 경험한 제품 개발 계획 수립 과정을 바탕으로, 저와 같은 고민을 하고 계신 분들께 도움을 드릴 수 있는 인사이트를 공유하고자 합니다.
스타트업에서의 초기 제품 개발 계획 수립 과정을 돌아보면 어린 시절 우리의 소중한 방학을 괴롭히던 “방학 계획표”가 떠오릅니다. 계획을 짜야한다는 것 만으로도 마음 한 켠이 무거웠기 때문입니다.
좌측 계획표 이미지 출처: YouTube 공부의 신 강성태
하지만 어릴 때 세우던 방학계획표는 사실 어려운 게 아닙니다. 왜냐면 ‘혼자’ 짜는 계획이니까요. 물론 이해관계자인 선생님과 부모님이 엄중하게 감독하는 경향이 있지만 결국 계획을 수행하는 사람은 나 혼자입니다. 반면에 계획을 수행하는 사람이 많아질수록 계획 수립의 난이도는 급격히 올라갑니다. 스타트업의 초기 제품 개발 계획 수립이 생각보다 까다로운 데에는 크게 세 가지 이유가 있습니다.
초기 제품 개발 계획 수립이 어려운 이유
1. 개인별로 제품 형상에 대한 이해도가 상이하다.
스타트업이 처음으로 제품을 개발하는 단계라는 뜻은, 아직 그 제품이 모습을 드러내지 않았다는 뜻입니다. 존재하지 않는 것을 만드는 중이니 만들어질 것에 대한 이해도가 모두 다를 수밖에 없습니다. 거기다가 같은 단어를 쓰더라도 그 단어에 대한 이해도가 개개인마다 모두 다릅니다. 반대 개념 중 하나인 SI와 SaaS를 예시로 들어볼게요.
💡 SI(System Integrator): 전산시스템을 필요로 하는 곳으로부터 하청을 받아, 시스템의 기획, 개발, 유지보수, 운영 등을 대신 해주는 업종
💡 SaaS(Software as a Service): 소프트웨어를 다운로드하지 않고도 인터넷을 통해 사용자가 액세스하는 모든 인프라, 플랫폼, 소프트웨어 또는 기술
사실 두 개념 모두 포괄적이고 큰 단위의 단어입니다. 하지만 두 단어가 대척점에 있는 것처럼 통상적으로 SI가 쓰일 때는 서비스 제공자가 직접 고객사 내부 시스템에 들어가서 솔루션을 제공하는 것이고, 클라우드는 고객사가 인터넷을 통해 원하는 솔루션에 접근하고 또 이를 사용할 수 있게 하는 개념이죠.
문제는 이 두 가지가 무 자르듯이 딱 구분되기 어렵다는 점입니다. 특히 초기에 우리 회사가 만든 제품이 SaaS를 지향한다고 해도 처음부터 버그나 오류에서 자유롭기는 어렵습니다. 그럼 SI처럼 고객사 내부 시스템에 접근해야 할 수도 있겠죠.
이러한 상황에 놓인 기업이라면 제품을 SaaS, SI 중 어떤 방향으로 만들어야 할까요? 사소해보일 수 있지만 팀이 지향하는 목표를 정렬한다는 점에서 매우 중요한 작업입니다.
2. 우리는 생각보다 추상적인 단어를 많이 쓴다.
🤣 “민성님, 저희 이번 데모 출시일이 언제죠?”
“?? 무슨 데모요??”
위 대화에서의 데모가 데모 웹사이트를 의미하는지, V1 제품의 데모인지.. 웹사이트 중에서도 아웃링크인 건지, 회사 홈페이지인 건지.. 알 수가 없습니다. 이런 단어들이 생각보다 많습니다. 파이프라인, 프로토타입, 콘텐츠 등등.. 추상적인 단어들에 대한 교통정리가 반드시 필요합니다.
이를 위해선 제품 하나를 출시할 때 함께 나올 결과물을 정하고 이에 대한 각각의 통일된 이름을 부여하는 작업이 필요합니다. 6월에 V1 제품이 출시된다고 가정하면, 6월 출시 전에 나올 제품의 프로토타입을 ‘v1 프로토타입’이라고 한다거나, ‘v0.5’라고 한다거나 이런 식의 이름에 대한 합의가 있어야 의사 소통에 들어가는 비용을 줄일 수 있습니다. 만약 v0.1, v0.2 등의 번호를 매긴다면 언제, 어떤 기능을 추가하면 버전 이름이 변경되는지 원칙을 정하는 작업도 필요하겠죠.
Project Management Tree Swing Cartoon
3. 여러 팀이 유기적으로 움직여야 한다
하나의 제품을 개발하는 데에 개발팀만 필요한 게 아니죠. 제품 출시를 위한 마케팅, 고객(혹은 고객사) 접점 만들기, 제품 디자인, 홈페이지 디자인, 콘텐츠 제작 등 많은 팀의 업무가 타이밍에 맞게 척척 진행되어야 합니다. 이 과정에서 팀은 다르지만 업무 연관성이 생기게 됩니다. 가령, ‘개발팀의 개발 이전엔 디자인팀의 화면 기획이 있어야 하고, 화면 기획이 있기 전에 제품 최소 기능에 대한 정의가 있어야 한다’는 식의 업무 연관 관계를 파악해야 하는 거죠. 계획 수립이 제대로 되지 않았다면 업무 순서가 꼬이고 계획이 늦춰지게 됩니다(사실 계획을 제대로 세워도 불가항력에 의해 늦춰지게 될 수도...😭). 미연에 방지하기 위해서는 결국 업무 간 연관 관계가 제대로 공유되어야 합니다.
제품 개발 계획 수립 프로세스
What과 Why에 대한 공유
초기 제품 개발에는 많은 사람들이 모이는 회의가 필수적입니다. 모든 회의가 그렇듯 이 회의는 왜 하는 것인지, 이 회의를 통해 내려고 하는 결과물이 무엇인지 공유하는 것이 필요합니다. ‘오늘 회의를 통해 우리 제품을 한 번에 이해시킬 수 있는 한 문장을 만든다’는 식의 단일 회의 목표도 있어야 하며, ‘제품 출시 로드맵을 통해 팀별 업무 연관성을 파악한다’는 큰 틀의 목표도 있어야 합니다.
참여 인원 확정
각 팀별로 중요한 의사결정을 하는 구성원이 들어가 있는지 확인해야 합니다. 사실 참여 인원은 계획 수립 과정에서 더 늘어날 가능성이 큽니다. 업무를 조율하다 보면 어떤 과정에서 예상치 못했던 업무가 등장할 수 있기 때문입니다. 인원이 너무 많아지지 않도록 조율하는 것도 중요합니다.
기술 및 제품 형상에 대한 이해도 일치
팀별로 배경지식이 다르니 모르는 용어가 많이 튀어나오고, 새로운 업무 방식을 마주하게 됩니다. 이 과정에서 모르거나 헷갈리는 것을 지체 없이 물어보는 것이 중요합니다. 모르는 것을 설명하는 과정에서, 서로가 제대로 확립하지 않은 개념에 대해 더 논의할 수 있습니다. 우리가 타깃으로 하는 고객 페르소나를 분석하거나, 경쟁사 분석 내용을 공유함으로써 팀원들의 전체적인 이해도를 올릴 수 있습니다.
제품 출시 과정에서 나올 output과 마일스톤 정하기
제품이 언제 나올지, 제품 출시까지 나와야 하는 다른 결과물들은 무엇이고 언제 나와야 하는지 정하는 것이 계획 수립의 큰 틀을 잡는 중요한 작업입니다. 6월까지 v1 제품 출시를 목표로 한다면 그 전까지 나와야 하는 결과물이 무엇인지 논의하고, 언제쯤 나와야 이상적인지 합의가 필요합니다. 해당 마일스톤을 기준으로 팀별 세부적인 업무가 붙을 것입니다.
프로젝트 관리를 쉽게 할 수 있는 협업 툴 정하기
앞서 언급했듯이 제품 개발 계획 수립의 목표가 팀별 업무 연관성 파악이라면, 이를 한 눈에 볼 수 있는 장표 혹은 차트가 필요할 것입니다. 요즘은 수많은 협업 툴이 프로젝트 관리를 쉽게 할 수 있도록 도와주고 있습니다. 협업 툴 내에서 output과 마일스톤을 찍고 그에 해당하는 업무를 써내려 가면 됩니다. 팀 지정, PIC(Person in Charge, 업무 책임자)를 정하고, 업무 시작일과 마감일, 해당 업무에 도움이 필요한 팀까지 지정해야 합니다. 대부분 협업툴은 리스트 형식, 보드 형식, 타임라인을 인터랙션 형태로 보여주기 때문에 업무 정리가 완료되면 한 눈에 프로젝트 관리 현황을 파악하기 쉽습니다.
하지만 이 과정에서도 어려움이 있습니다.
⚠️ Q. 어느 정도 세부적인 업무까지 공유해야 하나?
전체 프로젝트 관리 페이지에서는 버전별로 추가되는 기능 개발만 업무에 반영하고, 기획/개발 논의가 필요한 세부적인 업무는 기획/개발팀에서 따로 조율한다.
우리 제품을 출시하는 데에 기능이 여러 개가 있는데, 개발팀에서는 어느 정도까지 세부적으로 업무를 써야 할까요? 만약 개발팀에서 세부적으로 업무를 모두 쓰면 다른 팀에서는 그걸 이해하기 힘들어질뿐만 아니라, 사실 다른 팀이 세부적인 기술 업무를 파악하는 것은 불가능합니다. 가령 v0.1, v0.5, v1을 개발하는 것이 마일스톤이라면, v0.1 개발 자체를 한 덩어리로 묶고, v0.5 개발 업무는 v0.1 개발 당시 하지 않았던 큰 틀의 기능(혹은 개발 업무)만 쓰는 것이 적절할 것입니다. 실제 개발 업무를 할 때는 개발팀 내에서 더 상세한 workplan을 마련할테니까요. 이 과정에서도 업무별로 입자의 크기가 다를 수밖에 없습니다. 모든 입자를 맞추려고 시도하는 것보다 일단 큰 틀에서 계획 수립에 집중해야 합니다.
⚠️ Q. 결과물과 상관 없는 업무는 어떻게 정리하나?
마일스톤을 기준으로 결과물에 대한 계획 수립한다.
기획이나 개발의 경우 제품 출시와 직결되는 업무들이 대부분이지만, 마케팅 업무나 법무의 경우는 직접적으로 제품 출시와 연결되지 않을 수 있습니다. 가령 특허 출원 같은 업무가 있다고 해보죠. 이런 업무는 매우 중요하므로 프로젝트 관리 페이지에 보여야 하지만, 결과물과 연결되는 업무가 아닙니다. 이런 업무의 경우 마일스톤 날짜를 기준으로 시작일과 종료일을 설정하고 업무 연관 관계를 표시하면 됩니다.
⚠️ Q. 어느 정도 연관 있어야 업무끼리 연결짓나?
팀 내의 업무 연관성이 아니라, 타 팀과의 업무 연관성만 표시한다.
가만히 생각해보면, 모든 업무가 사실 연관성이 있습니다. 페르소나를 분석해야, 사용자 분석을 하고, 그래야 유저 테스트도 해보고.. 연관 관계를 만들려고 하면 한도 끝도 없이 만들어지고, 연관관계가 없다고 생각하면 아무 것도 연관관계가 없다고 생각할 수도 있습니다.
하지만 프로젝트 관리의 목표는 ‘타 팀과의 업무 연관성’을 확인하는 것입니다. 그런 차원에서 접근한다면 팀 내에서 업무 연관성을 그으려고 하기 보다는, 다른 팀과의 업무 연관성만 확인한다는 원칙을 세우는 편이 좋습니다.
마치며
사실 실무에서의 계획은 여러 예기치 못한 상황들로 인해 제대로 지켜지기가 어렵습니다. 맥이 빠지긴 하지만 계획을 제대로 잡고 팀별로 협업 포인트를 파악하는 것은 분명 효율적으로 일하는 데에 도움을 줍니다. 제품 출시 주기가 빨라야 하는 스타트업 입장에서는 제대로 된 계획이 이 주기를 짧게 하는 데에 분명 역할을 하기 때문입니다. 계획 세우기 귀찮은 우리들을 일깨워줄 따끔한 일침으로 글 마무리하겠습니다.😂
당신이 늘 계획을 세우지 않는다는 것은 당신이 늘 실패할 계획을 세우고 있다는 것과 같은 말이다. - 하이럼 스미스
Digitize Anything
-
업스테이지는 ‘Making AI beneificial’이란 미션 아래, AI로 더 이로운 세상을 만들어가기 위해 OCR Pack, 추천 팩 등의 AI 제품을 개발하고 있습니다. 업스테이지 홈페이지에서 자세한 정보를 확인해 보세요.
