내 기획은 왜 비즈니스 관점이 약할까?

– 문제 정의 제대로 하기

이 문서는 PM/기획자 지망생들이 사이드 프로젝트를 진행할 때 흔히 겪는 논리적 결여와 문제 정의의 막막함을 해결하기 위한 실무 가이드입니다.

단순한 기능 나열을 넘어,

실질적인 비즈니스 타당성을 갖춘 기획서를 완성하는 것이 목표입니다.

입문편에서 우리는 문제를 뾰족하게 정의하는 법을 다뤘습니다.

이번 실전편에서는 그 문제를 비즈니스 언어로 증명하는 방법을 이야기합니다.

1. PM 입문자의 딜레마

왜 내 기획서는 질문 몇 번에 무너지는가?

많은 입문 기획자들은 문제를 깊이 파고들기보다

‘내가 만들고 싶은 기능’을 먼저 정해두고 거꾸로 문제를 끼워 맞추는

솔루션 중심 사고(Solution-First Thinking)에 빠집니다.

“사람들이 이런 게 있으면 좋아할 것 같아요.”

이 문장은 비즈니스 관점에서 가장 위험한 신호입니다.

막연한 추측은 결국, 사용자가 실제로 돈이나 시간을 지불할 가치가 없는

자기만족형 프로젝트로 이어지기 쉽습니다.

입문자가 빠지기 쉬운 함정은 다음과 같습니다.

▪ 자기 객관화의 부재

“내가 불편하니까 남도 불편할 것”이라는 확증 편향에 갇혀 시장의 실제 수요를 간과합니다.

▪ 기능의 과잉

문제의 본질을 해결하기보다 화려하고 복잡한 기능을 나열해 기획서의 부실함을 감추려 합니다.

▪ 비즈니스 문법 미숙

기술적 구현 가능성(Feasibility)만 따질 뿐, 지속 가능한 수익 모델이나 운영 효율성에 대한 고민이 부족합니다.

2. 문제 정의의 기본과 발굴 기술

현상 뒤에 숨겨진 ‘돈이 되는 문제’를 찾는 법

기획의 시작은 단순한 불편함 나열이 아닙니다.

관찰된 현상을 비즈니스적으로 해결해야 할 진짜 문제로 치환하는 작업에서 출발해야 합니다.

2.1 현상(Phenomenon) vs 문제(Problem)

입문 기획자들이 가장 자주 범하는 실수는

눈에 보이는 현상 자체를 해결해야 할 문제로 오해하는 것입니다.

예를 들어,

▪ 사용자가 불안감을 느낀다

▪ 피로도가 높다

▪ 시스템이 복잡하게 느껴진다

▪ 불편해한다

이것은 관찰 가능한 상태일 뿐입니다.

이를 문제로 정의하려면 반드시

객관적인 도출 근거(Evidence)가 뒷받침되어야 하며,

타겟별로 세분화해 구체적인 손실 구조로 정의해야 합니다.

예시

▪ 현상

“사람들이 카페에 오래 앉아 있다.”

▪ 관찰된 지표(현상의 확장)

자리가 없어 불안, 콘센트를 찾느라 피로, 이용 방식이 복잡함.

▪ 도출 근거(Evidence)

뉴스 기사 수치, 평균 체류 시간 데이터, 유저 인터뷰 등.

▪ 타겟별 문제 세분화

▪ 카페 주인: 회전율 저하 → 시간당 매출 30% 감소

▪ 공부하는 손님: 자리 불확실성 → 작업 흐름 단절

▪ 일반 손님: 소음과 복잡성 → 재방문 의사 하락

문제는 ‘불편함’이 아니라 정량화 가능한 손실입니다.

Painkiller vs Vitamin

▪ Painkiller(진통제): 해결하지 않으면 손해가 발생하거나 일상이 마비되는 문제

▪ Vitamin(비타민): 있으면 좋지만 없어도 생존 가능한 니즈

입문자들이 가장 어려워하는 부분은 니즈와 페인포인트를 구분하는 일입니다.

비즈니스는 대체로 진통제 영역의 문제에서 시작됩니다.

2.2 체계적인 문제 발굴: 문제의 목록화(Problem Inventory)

머릿속의 아이디어를 객관화하려면

엑셀이나 스프레드시트를 활용해 문제 인벤토리를 작성해야 합니다.

최소 10개 이상의 현상을 나열하고 다음 기준으로 정리합니다.

1.관찰된 현상

2.대상 타겟

3.진짜 문제(Pain Point)

4.비즈니스 문제(지표 하락과의 연결)

예시:

▪ 현상: 배달비가 비싸다

▪ 타겟: 1인 가구 자취생

▪ 진짜 문제: 식비 지출 통제 불능

▪ 비즈니스 문제: 주문 빈도 감소 및 앱 이탈

2.3 타겟 정의 및 크기 추정 (Target Sizing & Definition)

문제를 정의했다면,

그 문제를 겪고 있는 사용자의 실체와 규모를 파악해야 합니다.

특성 기반 타겟 정의

▪ “대한민국 모든 직장인” ❌

▪ “연소득 3,600만 원 미만의 결혼·출산 고민을 가진 2030 청년” ⭕

▪ “무신사 전체 회원” ❌

▪ “수도권 외 지역 거주로 오프라인 접근성이 제한된 800만 명” ⭕

타겟은 ‘모수’가 아니라 제약과 결핍을 가진 집단입니다.

타겟 크기 추정 방법 (Ratio Estimation)

1.모수 확인

공식 통계나 기업 데이터를 통해 전체 숫자를 찾습니다.

2.비율 적용

설문조사, 기사, 논리적 근거를 통해 해당 조건의 비율을 곱합니다.

계산 예시

▪ 대한민국 1인 가구 750만

▪ 그중 배달비 부담 60%

→ 450만 명

▪ 그중 서울 거주 20%

→ 90만 명

이 과정은 단순 계산이 아니라 논리 구축의 과정입니다.

타겟의 빈도와 해결 의지

타겟이 크다고 항상 좋은 것은 아닙니다.

▪ 문제 발생 빈도

▪ 기존 대안에 대한 불만

▪ 해결 의지

▪ 리스크 고려

▪ 최종 ROI(비용 대비 효과)

이 모든 요소를 고려해야 합니다.

3. 논리적 공백 메우기

‘무한한 자유’ 속에서 기준 세우기

사이드 프로젝트에는 회사, OKR, 예산 같은 제약이 없습니다.

이 무한한 자유는 오히려 기획의 인과관계를 흐리게 만듭니다.

따라서 제약을 인위적으로 설정해야 합니다.

예:

▪ “3개월 내 유료 고객 100명 확보”

▪ “물류 비용 15% 절감”

제약이 있어야 문제와 해결책 사이의 논리가 명확해집니다.

4. 비즈니스 시뮬레이션 3대 유형

SI/솔루션 제안형

▪ 임원 승인을 받기 위한 수치 중심 설계

▪ 계약 범위, 기간, 기술적 호환성 고려

정부지원 과제형

▪ 정책 부합성

▪ 예산 집행 규정

▪ 공공성

스타트업 피칭형

▪ 유저 사용 증거

▪ 한정된 자본

▪ 피봇 전략

같은 아이디어라도

비즈니스 문맥에 따라 기획의 언어는 달라집니다.

[별첨] PM용 비즈니스 타당성 체크리스트

▪ 체크리스트: 기획의 방향성 자가 검토 (Drafting 단계)

▪ 활용법: 기획서의 초안을 완성한 후, 각 항목에 대해 "Yes/No"로 답해 보세요.

▪ 핵심 팁: 하나라도 "No"가 나온다면 그 부분에서 논리적 비약이 발생할 확률이 높습니다.

특히 "타겟의 실체" 항목에서 막힌다면, 기획을 멈추고 당장 3명의 잠재 유저를 인터뷰하여 기획의 근거를 보강해야 합니다.

기획서 초안을 완성했다면 다음 질문에 냉정하게 답해보세요.

PM용 비즈니스 타당성 체크리스트

이 질문들에 명확히 답하지 못한다면 논리를 다시 점검해야 합니다.

마무리

이 가이드는 단순한 작성법이 아닙니다.

비즈니스 관점으로 사고하는 훈련 도구입니다.

입문편이 ‘문제를 뾰족하게 정의하는 법’이었다면,

실전편은 ‘그 문제를 비즈니스 언어로 증명하는 법’입니다.

기획은 아이디어가 아니라 논리입니다.

그리고 그 논리는 근거와 제약 위에서 완성됩니다.