스타트업은 왜 문제 정의에서 막힐까
아이디어가 없는 게 아니라, 문제를 말로 못 옮긴다
스타트업의 창업멤버로 있으면서, 재직 내내 예비창업패키지, 초기창업패키지, 창업성장기술개발사업, 데이터 바우처.. 등등 거의 조건이 되는 국가 과업들은 다 지원해봤던 것 같다. (결국 하나도 선정되지 못했지만)
나 역시, 가장 쓰기 어려웠던 부분이 '문제정의' 부분이었다.
서비스 화면도 있고, 기능 설명도 술술 나오는데 이상하게 이 문단만 쓰기 어렵다.
이미 만들고 싶은 건 분명한데, 문제를 쓰려니 말이 추상적으로 흐려진다.
'내가 해보니까 불편해서','비효율적이어서' 식의 문제정의부터 시작해서, 그 산업의 문제를 끌어오기 위해 산업의 규모부터 신문기사 스크랩해서 붙이고 억지로 문제를 만들어서 엄청 큰 문제처럼 보이게 하는 데 혈안이었다.
문제 파악을 위해서 직접 시장에 나가서 인터뷰도 해보고, 시제품 만들어서 검증도 해보고 하라는데
그럴 수 없는 여건에 놓인 스타트업들이 태반이다.
또한 선정된 업체들을 보면 이미 매출이 몇 십억씩 난 기업도 있다.
(이게 정말 예비 창업, 초기 창업이 맞는 취지의 사업인지 아리까리하기도 하다.)
그래서 더욱 문제 정의를 잘 하고, 정말 시장이 가지고 있는 불편함에 공감하고 해소할 수 있는지에 대한 기준을 마련한 기업들을 찾는 게 하늘의 별따기 같다. 나 역시, 지금 보면 나만 불편했던 것들이고 시장이 정말 해소하고자 하는 불편함이 아니었다.
스타트업들이 아이디어가 없어서가 아니다. 오히려 반대다.
솔루션은 이미 너무 선명한데, 그걸 문제의 언어로 옮기지 못하고 있다.
평가자는 문제부터 보는데, 대표는 계속 솔루션 이야기만 하고 있는 상태다.
“내가 문제 정의를 못 하는 사람인가?”
아니다. 대부분의 경우 문제를 못 찾은 게 아니라, 아직 제대로 꺼내 쓰지 않았을 뿐이다.
문제는 이미 솔루션 안에 들어 있다. 다만 그게 정말 문제인가?를 판별할 수 있는 시도와 평가자가 이해할 수 있는 순서와 언어로 풀어내는 연습이 필요하다.
Step 1. 현상과 현재 객관적 상태 파악
해결책은 잠시 내려놓고, 지금 사람들이 무엇을 하고 있는지부터 쓴다. 판단이나 해석은 최대한 배제한다.
예를 들어 ‘중소기업용 프로젝트 관리 SaaS’를 떠올렸다면
지금 팀들은 프로젝트를 어떻게 관리하고 있는가.
→ 엑셀 파일을 공유한다, 메신저에 진행 상황을 남긴다, 주간 회의에서 구두로 정리한다.
이 단계에서는 “비효율적이다” 같은 말은 쓰지 않는다. 관찰한 행동만 기록한다.
Step 2. 행동에 대해 ‘왜’를 반복하기
기록한 행동 하나를 붙잡고 “왜?”를 여러 번 묻는다. 표면 아래에 있는 이유를 찾는 과정이다.
왜 엑셀로 관리할까? → 이미 모두가 쓰고 있고, 새 툴을 도입하기 부담스럽기 때문이다.
왜 메신저에 남기는 걸까? → 따로 정리할 시간이 없고, 이동하면서도 보기 편해야하기 때문이다.
왜 구두 보고에 의존하는가. → 문서로 남길 책임을 지고 싶지 않기 때문이다.
이 과정이 지나면 문제는 ‘툴이 없다’가 아니라 ‘관리 비용을 감당할 여력이 없다’로 이동한다.
Step 3. 불편함이 실제 행동으로 나타나는지 확인
사람들이 정말로 이 문제를 불편해하고 있는지는 말보다 행동을 보면 알 수 있다.
업무 누락을 줄이기 위해 회의 시간을 늘리고 있는가
야근으로 정리를 대신하고 있는가
중간 관리자가 개인 메모나 별도 문서를 만들고 있는가.
(쓰다보니 내 얘기 같다)
이미 추가 행동이 발생하고 있다면, 문제는 실제로 존재한다고 볼 수 있다.
Step 4. 문제의 빈도와 강도를 구분
문제가 비즈니스가 되려면 자주 발생하거나, 발생했을 때 꽤 아파야 (?) 한다.
(고빈도) 프로젝트 관리 혼선은 거의 매주 발생한다.
(저강도) 하지만 소규모 팀에서는 참고 넘어갈 수 있다.
강도는 팀 규모에 따라 달라진다.
이 판단이 “이 문제가 누구에게 가장 아픈가”를 결정한다.
예비창업패키지에서 말하는 타겟 고객 정의로 이어지는 지점이다.
이 구분이 문제의 성격과 시장 크기를 가늠하게 해준다.
Step 5. 문제를 한 문장으로 고정한다
마지막으로 문제를 문장 하나로 묶는다. 이 문장은 이후 모든 설명의 기준점이 된다.
“중소 규모 팀은 여러 프로젝트를 동시에 운영하는 상황에서,
업무 진행 상황을 한눈에 파악하기 어려워 반복적인 커뮤니케이션과 관리 부담을 겪고 있다.”
정의한 문장이 어색하거나 논리적으로 부족하다는 생각이 든다면,앞 단계 중 어딘가가 아직 덜 정리된 상태다.
문제 정의는 이렇게 앞뒤로 오가며 다듬어야 하며, 가장 오랜 시간이 걸리는 과정이기도 하다.
그러면 어떻게 다듬어야 할까?
[2차 문제정의 다듬기]
① 문제가 발생하는 구체적 맥락
지금 문장은 “여러 프로젝트를 동시에 운영하는 상황”이라고 말한다.
하지만 심사위원은 여기서 한 번 더 묻는다.
'언제? 어떤 팀에서? 어떤 순간에?"
② 문제의 결과(손실)
“관리 부담”은 상태 설명이다.
완성도 높은 문제 정의는 그 부담이 어떤 손실로 이어지는지까지 말한다.
③ 기존 대안이 왜 충분하지 않은지
왜 이 문제가 아직 남아 있는지도 드러나야 한다.
그래야 “굳이 새로운 솔루션이 필요한 이유”가 생긴다.
지금 문장을 쪼개서 한단계씩 업그레이드 해보면 다음과 같다.
[기존 정의 문장]
1. 중소 규모 팀은 여러 프로젝트를 동시에 운영하는 상황에서,
2. 업무 진행 상황을 한눈에 파악하기 어려워
3. 반복적인 커뮤니케이션과 관리 부담을 겪고 있다.
1단계 개선: 맥락을 좁힌다
중소 규모 팀은 여러 프로젝트를 동시에 운영하는 과정에서, 각 프로젝트의 진행 상황과 담당자별 업무 상태를 실시간으로 파악하기 어렵다.
→ “한눈에” 같은 추상어가 줄고, 무엇이 안 보이는지가 분명해진다.
2단계 개선: 손실을 드러낸다
그 결과, 중소 규모 팀은 반복적인 진행 확인과 불필요한 회의를 통해 관리에 과도한 시간을 쓰고, 의사결정이 지연되는 문제를 겪고 있다.
→ 문제를 겪는 대가가 보이기 시작한다.
3단계 개선: 왜 아직 해결되지 않았는지를 넣는다
이는 기존 협업 도구들이 일정 관리, 커뮤니케이션, 문서 관리가 분절돼 있어
팀 전체의 업무 흐름을 한 화면에서 파악하기 어렵기 때문이다.
→ “그래서 새로운 솔루션이 필요하다”는 논리가 자연스럽게 열린다.
완성도 높은 문제 정의 문장
위 세 단계를 하나로 합치면, 심사 기준에서 꽤 강한 문장이 된다.
[문제 현상]
중소 규모 팀은 여러 프로젝트를 동시에 운영하는 과정에서
프로젝트별 진행 상황과 담당자별 업무 상태를 통합적으로 파악하기 어려워
[손실]
반복적인 진행 확인과 회의에 많은 관리 시간을 소모하고,
그로 인해 의사결정 지연과 업무 누락의 위험을 겪고 있다.
[해결되지 못한 이유]
기존 협업 도구들은 기능이 분절돼 있어 이러한 문제를 충분히 해결하지 못하고 있다.
많은 사람들이 문제 정의를 ‘한 번에 잘 써야 하는 것’이라고 생각한다.
하지만 문제 정의는 완성본이 아니라 가설에 가깝다. 외부 자료를 찾아보고, 시장 데이터를 보고, 실제 사람을 만나면서 계속 수정된다.
이 과정에서 처음 생각했던 문제는 작아질 수도 있고, 전혀 다른 방향으로 바뀔 수도 있다.
그래서 스타트업을 창업하기 전, 이런 문제점을 드릴다운해서 정말 깊게 고민해보고,
여러가지 문제점을 찾아내는데 많은 시간을 들여야하는 것 같다.
한국 스타트업들은 정말 아이디어가 많다고 생각한다. 그래서 창업을 지원하는 프로그램들이 정말 취지에 맞게 잘 돌아갔으면 한다. 특히 이 시기에 고군분투하실 스타트업 대표님들, 시제품화가 상용까지 성공해서 더욱 빛나게 하는 데 이 글이 일조할 수 있기를 바란다.
