[서비스 기획 입문] 1 : 문제 정의부터 해결까지

이번주 부터 본격적인 서비스 기획 입문에 대한 포스팅을 시작할 예정이다!

 

사실 지금까지는 무언가 올릴때마다 gpt의 도움을 받았었는데, 올리다보니 이게 학습에 있어서는 되게 별로인 방법이구나, 를 뒤늦게 깨달았다. 그래서 서툴더라도 한번 내가 처음부터 끝까지 퇴고까지 스스로 하면서 진행해보려한다.

 

다른 분들 블로그 포스팅 포스팅을 보니, 포스팅 서두에 그날그날의 기분이나, 음악 추천을 해주시더라. 그래서 나도... ㅎㅎ 조심스럽게 내 취향 플리를 올려보려고 한다.

 

https://www.youtube.com/watch?v=YUUfw9Jsl5Y&list=RDYUUfw9Jsl5Y&start_radio=1

 

나는 유독 ‘외국어 노래를 한국어로 개사해서 부르는 곡’을 참 좋아한다.
외국 음악이든 영화든, 내용이 온전히 내게 와닿아야 직성이 풀리는 성격이라서 그런 것 같다.

일본 특유의 감성을 좋아하지만,
그 감정선이 언어 장벽에 가려져 있을 때면 늘 아쉽다.
그래서 난 자주 유튜브에서 한국어 개사곡을 뒤적이고 다닌다.
조회수는 많지 않지만, 그런 영상들에서 진짜 보석 같은 노래들을 종종 발견한다.

 

오늘 추천한 곡도,
그렇게 우연히 찾은 친구 같은 노래다.
혹시 취향 맞는 분들이 있다면 한 번 들어봐 주셨으면 한다.

테시마 아오이의 ‘숲속의 작은 레스토랑’.
처음엔 평화롭고 따스한 멜로디에 마음이 포근해지지만, 그냥 들으면 산뜻하고 잔잔한 분위기의 동요같지만 가사를 천천히 들여다보면 좀 ... 깊다!

-“어서 오세요, 잘 오셨어요. 실컷 먹었다면 주무세요”
-“무덤 안까지 배달해 드릴게요. 오늘 밤은 마지막 풀 코스니까요”

그 레스토랑은 어쩌면 현실 어딘가가 아니라, 삶이 끝난 이후 마지막으로 다정한 저승사자에게 대접받는 한끼 식사같아서. 그 식당에서 저승사자한테 내 일생은 이랬다면 행복한 기억들을 추억하는 것 같아서 되게 좋아하는 노래이다.
나는 원래가 이렇게 동화적이거나 따뜻한 이야기 속에 슬며시 스며든 노래를 좋아한다. 이런 노래... 더 소개해보겠다....

---

 

 

지금껏 올린 포스팅들을 되돌아보면 공통적으로 올린 내용은

"pm은 문제정의와 해결을 잘 해야한다!"하는 이야기였다.

 

그렇다면~, 잘해야하는 건 이제 알겠는데 잘해야하는 이유는 무엇일까? 

서비스 기획 입문 첫 포스팅에서는 그것부터 알아보려고한다.

 

---

 

1. 문제정의와 해결을 잘해야하는 이유!

 

1- 문제정의를 잘하면 프로덕트의 가치가 향상된다.

 

문제정의가 중요한 이유는 단순하다.

진짜로 해결해야 할 ‘사용자 문제’를 제대로 해결해줄 수 있어야, 사용자는 계속 그 프로덕트를 쓰게 되고,그래야 비즈니스 가치도 자연스럽게 따라온다. 문제정의를 제대로 하지 않으면, 겉보기엔 그럴싸한 기능을 쌓아도 **사용자 니즈랑 엇갈린 ‘겉도는 기능’**만 양산되기 쉽다.

그럼 사용자는 이탈하고, 프로덕트는 애매해지고, 결국 비즈니스 가치도 생기지 않는다.

 

정말 중요한 건,

-지금 우리가 풀고 있는 이 문제가, 사용자가 진짜 겪는 문제인지?
-이걸 풀었을 때 사용자 경험이 얼마나 나아지는지?

- 를 명확하게 짚고 가는 것이다.

 

 

2. 원활한 협업은 문제 정의에서 시작된다. 

디자이너나 개발자가 프로젝트에 참여할 때 가장 먼저 궁금해하는 건 이거다.
“이걸 왜 하는 거지?” 라는 질문이다.

 

실제로 나도 디자인을 하던 시절에,
“지기구조가 구조적으로 독특한 패키지 벤치마킹 해오세요”
라는 요청을 받았을 때, 제일 먼저 든 생각은
“이거 어디에 쓸 건데?” 였다.

 

그래서 찾아가서 물어봤다.
“이게 왜 필요한데요?”

그랬더니 돌아온 대답은 이랬다.
“양주의 안정성이 유지되면서도 외관이 독특해서 눈에 띄는 패키지를 만들고 싶어서요.”

 

그제야 나는 벤치마킹을 어떤 방향으로 해야 하는지 알 수 있었다.

• 양주가 보관될 수 있을 만한 크기
• 안정성을 위한 완충성과 두꺼운 종이 재질
• 외관은 시선을 끌 수 있는 구조

문제 정의가 명확해졌을 때,
그 일을 왜 해야 하는지도 자연스럽게 이해가 됐다.

그렇지 않으면 팀원들은 그냥 “시키니까 하는 기분”으로 일하게 된다.
일에 공감이 생기지 않으니, 사기도 자연스럽게 떨어진다.

그래서 PM의 역할이 중요하다.

“우리가 지금 해결하려는 문제는 무엇인지”,
“그 문제를 해결하면 어떤 변화가 있는지”

 

이 두 가지를 명확하게 정의해서 팀원들과 공유해야 한다.

디자이너나 개발자들은 보통 프로덕트의 기획보다는 실행 단계에서 고민을 시작하는 경우가 많다.
그래서 프로젝트의 시작 배경을 잘 모르면, 일 자체가 납득되지 않고 동기부여가 어렵다.

 

PM이 문제 정의를 잘하면,
팀원들도 자신이 하는 일의 이유를 이해하게 된다.
이해가 생기면, 자연스럽게 협업도 잘 이루어진다.

결국, 협업은 문제 정의에서 시작된다.

 

---

 

문제정의 잘하는 방법?

 

1.문제정의도 어느정도의 사전지식이 있어야한다. 

요즘 GPT 사용법 관련 콘텐츠를 자주 본다.
그중에 가장 공감했던 문장이 있다.

“GPT의 답변 퀄리티는, 질문자의 질문 수준에 달려 있다.”

 

질문을 잘해야 답을 잘 얻는다는 말.
사실, 이건 사람 사이에서도 통하는 이야기다.
그렇다면 현업에서 발생하는 ‘문제’를 정의하는 건 어떨까?

 

문제정의는 단순히 ‘이상한 점’을 지적하는 게 아니라,
올바른 배경지식과 맥락 이해를 바탕으로 “진짜 해결해야 할 것”을 추리는 일이다.

그러기 위해선 팀원 혹은 PM이 이런 정보들을 두루 갖추고 있어야 한다.

-우리 고객이 어떤 니즈를 가지고 있는지
-고객의 니즈를 모른다면, 어떤 UX 리서치 방식이 적절한지
-우리가 속한 시장은 어떤 흐름을 타고 있는지
-우리 팀의 OKR은 무엇이고, 지금 이 목표가 중요한 이유는 뭔지
-우리가 만든 서비스의 기본적인 장단점은 무엇인지

 

이런 모든 정보가 문제를 올바른 방향으로 바라보게 해주는 뿌리가 되어준다.
문제정의가 어려운 건, 그 뿌리가 아직 튼튼하지 않기 때문일 수도 있다.

 

그러니, 내가 지금 문제정의가 너무 어렵다면?

-> 내 배경지식, 리서치가 부족한게 아닐까? 생각해보고 도메인 공부부터 해보길 추천한다.

 

 

2.논리적인 사고를 해야한다.

 

예전에 썼던 커뮤니케이션 포스팅에서
**“말과 글에는 논리와 근거가 필요하다”**고 했던 기억이 있다.
사실 이건, 단순히 말을 잘하기 위해서가 아니라 문제를 제대로 이해하기 위해서도 꼭 필요한 습관이다.(pm은 말도 잘해야하긴 하다)

 

논리적인 사고를 한다는 건,
단순히 ‘맞는 말’만 하는 게 아니라
-내가 가진 정보들 속에서 문제를 정확히 뽑아내고,
-그 문제로부터 해결책을 구조화해서 뻗어나가는 과정이다.

 

정리하자면,

논리적인 사고는 문제를 ‘분석’하고 ‘확장’하는 도구다.

 

그렇다면, 논리적인 사고는 타고나는 걸까?
그렇지만은 않다. 물론 타고나면 좋겠지만, 우리 모두가 논리적인 능력을 갖고 태어날 순 없으니(내가 완전 키워야할 역량이다.)

 

다행히도 논리적인 사고를 돕는 도구들이 있다. 이후 포스팅에서 세부적으로 설명할테지만 예고하자면 5whys 방법론, 로직트리가 대표적이다. 

 

자세한 내용이 알고싶다면, 다음 포스팅을 보고 한번 익혀보길 바란다 .

나처럼 머릿속이 자주 뒤엉기는 사람들에게 도움이 될것이다(나도 너무 많은 도움이 되었다)

 

 

3. 문제정의, 실무 사례를 많이 접해봐야 감이 온다

 

사전지식도 있고, 논리적인 사고도 어느 정도 익혔는데
막상 문제정의를 하려 하면 머리가 하얘지는 경우가 있다.
왜 그럴까?

그건 실무의 맥락을 제대로 겪어본 적이 없기 때문이다.

 

실제로, 이 해당 강의를 해주신 튜터님께서도 서비스 기획자로서 문제를 '정의'하고 '해결'해야 하는 상황을 상상해보면,
이건 단순한 논리로만은 안 풀린다고 하셨다.

• 어떤 상황에서,
• 어떤 유저가,
• 어떤 문제를 겪었는지
• 그 문제를 해결하면 어떤 성과로 이어지는지를

경험적으로 감각할 줄 알아야 한다.

 

 

그래서 요즘은 가능한 많은 실무 사례들을 접해보려 한다.
실제로 서비스를 써보면서

“이건 왜 이렇게 만들었을까?”
“이 개편은 어떤 데이터를 근거로 했을까?”

이런 생각을 스스로 해보는 연습도 도움이 많이 된다.

 

 

아티클도 꾸준히 읽어야 한다.
배달의민족, 토스, 당근마켓 같은 국내 프로덕트팀의 글들을 보면서
실무자가 진짜 고민했던 포인트,
그리고 그들이 “문제를 어떻게 정의했는지”를 역추적해보면
슬슬 나도 어떤 스타일의 문제정의가 설득력 있는지를 감으로 익히게 된다.

실무 사례를 많이 보면,
결국 ‘직관’이 생긴다.
그리고 그 직관이 ‘경험’이 된다.

---

💭 그럼, 문제란 도대체 뭘까?
살짝 철학적인 질문처럼 느껴질 수도 있다.
하지만 기획자에겐 이 질문에 답하는 감각이 무엇보다 중요하다.

 

 

문제란, 현재 상태(As-is)와 바람직한 상태(To-be)의 차이를 말한다.
그리고 이 차이(간극)를 줄이기 위해 우리가 움직이는 거다.

때론 잘못된 점을 해결하기 위해,
때론 새로운 기회를 더 크게 만들기 위해.

결국, 문제정의란

**“무엇이 잘못됐고, 무엇이 가능하며, 무엇이 개선되어야 하는가”**를
명확하게 정의하고 설명하는 작업이다.

 

이런 생각을 하다 보면
내가 보는 서비스 하나하나가 전부 ‘공부 대상’처럼 보인다.
그게, 진짜 실무를 준비하는 자세가 아닐까 싶다.

 

---

 

 

토스의 대표가 말하길(좋은 전략 예시 아티클 분석 링크)

https://ljyljy0813.tistory.com/37

[아티클 분석] 토스의 전략: ‘좋은 전략’이란 무엇일까?

 

[아티클 요약]

전략이란 어떤 목표에 도달하기 위한 가장 최적의 방법을 의미한다. 이 전략에는 두 가지 핵심 단계가 필요한데, 첫째는 현재 우리가 처한 두렵거나 좋지 않은 상태를 정확히 인식하는 것이고, 둘째는 앞으로 우리가 도달하고자 하는 바람직한 비전을 명확히 정의하는 것이다. 결국 전략이란 현재 상태(As-Is)와 바람직한 상태(To-Be) 사이의 차이를 좁히기 위한 행동의 방향을 설정하는 작업이며, 이 차이를 줄이기 위해 어떤 우선순위로 어떤 액션을 취할지 명확히 정리된 상태가 되어야 한다. 즉, 모두가 동의할 수 있는 우선순위와 실행계획이 공유된 상태여야만 전략이 ‘존재한다’고 할 수 있으며, 만약 현재와 미래의 상태 정의가 명확하지 않다면 그것은 좋은 전략이라고 볼 수 없다.

---

문제해결 단계

문제 해결이 중요한건 pm 공고를 분석하면 알 수 있는데-,

 

 

당근 PM 공고

이런 일을 해요:
-누구나 동네에서 좋은 일자리를 찾고 도움을 구할 수 있는, 당근알바 서비스의 제품 개선 및 운영을 담당해요.
-사용자, 서비스, 비전에 대한 높은 이해를 바탕으로 유저 경험을 개선하고 만족도를 높여 안정적으로 서비스 성장을 만들어요.
-사용자 인터뷰와 데이터를 기반으로 문제점을 발견하고, 가설을 수립하며, 검증을 위한 실험을 진행해요.
-엔지니어, 디자이너의 역할을 이해하고 협업을 통해 유저의 문제를 가장 정확하고 빠르게 해결할 방법을 도출하고 실행해요.
-마케팅팀과 협업하여 당근알바의 성장을 지속해요.

 

 

토스 PM 공고

"문제 정의 - 가설 수립 - 액션 및 검증 - 결과"

이력서는 이렇게 작성하시는 걸 추천해요:
-제품/서비스/프로젝트별 "문제 정의 - 가설 수립 - 액션 및 검증 - 결과"의 요소들을 명확히 기재해 주세요.
-해오신 업무의 단순 나열이 아닌 임팩트 및 러닝 포인트를 적어주신다면 강점이 돋보일 거예요.

 

 

팀스파르타 PM 공고
 팀스파르타의 pm 공고같은 경우는 진짜 자상하게 나와있는 편이라 공부하기 좋다한다.

Growth Product Manager는 이렇게 일해요
• 논리적이고 유쾌한 사고를 할 수 있고, 숫자로 이야기하기를 좋아하며, 아이디어를 실현하는 실행력을 갖추신 분이라면 즐겁게 일할 수 있을 거예요.
• 디자이너, 개발자, CX 등 비즈니스 이해도가 높은 스쿼드에서 원팀으로 일하며, 높은 자유도를 바탕으로 다채로운 실험을 진행할 수 있습니다.
• Amplitude, Hackle, Mixpanel, Redash, Beusable, Zapier과 같은 tool 활용은 물론, 자체 개발된 백오피스를 통해 디자이너와 개발자의 도움 없이도 빠른 실험을 할 수 있는 환경이 구축되어 있습니다.

1) 문제 정의 방법
• 예시 상황: 지난 주 대비 매출 트렌드가 떨어졌다.• 단편적 문제 정의
결제 전환율이 지난 주 대비 20% 떨어진 것이 문제다. (현상 = 문제라고 정의)
• 스파르타적 문제 정의
주요 결제 페르소나인 개발 초보자의 불안감을 해소할 액션이 없는 것이 문제다. (현상의 원인 = 문제라고 정의)
• 문제 정의 방식
결제 전환율이 지난 주 대비 20% 떨어졌다. 어떤 퍼널에서 전환율이 떨어졌을까? (퍼널 분석)
결제 직전 퍼널에서 전환율이 떨어졌다. 결제를 한 사람들은 어떤 사람들일까? (페르소나 정의)
결제자의 90%는 개발 초보자다. 이들은 왜 지난 주에 결제했을까? (결제 원인 파악)

=> 지난 주, 개발 초보자의 불안감을 해소하기 위한 혜택 프로모션이 마감되었다. 현재, 주요 결제 페르소나의 불안감을 해소할 액션이 없다.

2) 가설 설정 방법
• 예시 상황: '지원동기 제출' 퍼널에서의 전환율이 낮다.• 단편적 가설 설정
지원동기 예시 카피를 변경하면 유저들의 지원서 제출률이 늘어날 것이다.
• 스파르타적 가설 설정
가설의 근거 수집: 지원동기 작성 퍼널에서 이탈하는 유저의 90%는 직장인이다.가설: 직장인 지원동기 예시를 보여주면 공감대를 형성해 불안감을 해소할 수 있어 → 이탈 유저 90% 중 30%가 지원서를 제출할 것이다. 어떤 예시가 더 효율이 좋을지 A/B Test 실험을 설계해보자!

3) 액션 진행 및 성과 파악
• 예시 상황: 기존 부트캠프 코스의 포지셔닝을 피봇하여 수요가 있는지 테스트 한다.• 단편적 액션
디자인 1주 + 개발 2주로 설정 후 한 달 뒤에 배포 후, 결제자가 늘었는지 측정한다.
• 스파르타적 액션
개발, 디자인 리소스 없이 노코드툴을 활용해 빠르게 테스트하고, 하루 만에 페이지를 배포한다.광고 효율, 랜딩페이지 PV, CTA 클릭률, 피봇된 UTM으로 인입된 고객의 전환율을 따로 측정한다.

 

정리하면,

결국 PM은 ‘목표수립-문제정의-가설수립&검증’의 프레임워크로 고민해야 합니다.

 

1. 목표 수립 : as is

-해결하고자 하는 문제의 상위 버전의 목표를 정의

사용자/비지니스가 가치관점에서 달성해야할 핵심 지표를 설정

 

2. 문제정의: as is와 to be의 갭을 줄이기 위함

-수많은 문제 중 해결해야하는 핵심 문제를 정의

-문제의 핵심 원인 분석

 

3. 가설 수립 : 문제 해결을 위한 가설수입

-문제 해결을 위한 검증 가능한 가설을 세움

-가설 검증을 위해 다양한 액션(기능 개발, 실험등) 실행

-결과 데이터를 분석해 가설 검증 & 개선 반복

 

4. 검증 : 가설이 맞는지 검증

 

 

---

참고 아티클 -

쏘카 PM의 차량 예약 퍼널 단계 개선기(feat. AB TEST)

https://tech.socarcorp.kr/product/2022/06/02/reservation-funnel-improvement-with-abtest.html

쏘카 PM의 차량 예약 퍼널 단계 개선기(feat. AB TEST)

 

-> 결론 요약 : 문제를 정의하고 가설에 기반에 검증하는 사고방식이 중요하다는 이야기

이 아티클의 핵심은 문제 정의와 가설 기반 검증의 중요성에 대한 설명입니다. 쏘카 PM인 루시아는 부름 서비스의 예약량 증가를 목표로 AB TEST를 활용해 사용자 경험을 개선하는 방법을 공유합니다.

요약:

-문제 정의:
사용자 문제를 정확히 파악하려면 기존 문제를 단순히 관찰하는 것에서 그치지 않고, 사용자의 관점에서 문제를 정의해야 합니다. 루시아는 부름 서비스의 예약량이 정체된 원인을 찾기 위해 부름을 어떻게 사용자에게 전달할 것인지에 대한 고민을 시작합니다.

-가설 설정 및 검증:
문제를 정의한 후, 가설을 세우고 검증하는 과정이 중요합니다. 루시아는 부름 서비스 예약 흐름을 개선하기 위한 새로운 UX 설계를 하며, A/B 테스트를 통해 사용자의 반응을 데이터 기반으로 검증합니다. 이 과정에서 기존 UX와 새로운 UX의 차이를 비교하고, 실험군과 대조군을 설정해 결과를 확인합니다.

-A/B 테스트:
A/B 테스트는 가설이 맞는지 확인하고, 실제 데이터를 통해 효과성을 검증하는 데 사용됩니다. 루시아는 부름 서비스의 예약 페이지에서 사용자의 전환율을 높이기 위해 새로운 UX를 도입하고, 그 결과를 지표로 확인합니다.

-결과와 개선:
실험 결과, 새로운 UX는 예약 전환율을 21.8% 개선했고, 부름 서비스의 매력을 전달하는데 성공했습니다. 이 데이터를 바탕으로 전체 서비스에 적용할 수 있는 결론을 내렸습니다.

-데이터 기반 사고의 중요성:
이 과정은 데이터 기반 사고와 가설 검증을 통해 문제를 해결하는 중요한 예시로, A/B 테스트를 통한 실험적 접근이 PM의 역할에서 얼마나 중요한지 강조합니다.

-핵심 포인트:
문제 정의는 사용자의 관점에서 정확히 파악해야 하며,
가설 설정 후 A/B 테스트로 검증하는 것이 제품 개선에 매우 중요한 과정입니다.
이 방식은 서비스 개선과 혁신을 위한 필수적인 방법론을 잘 보여줍니다.

 

---

 

최종 정리!

이런 사고방식이 왜 필요할까??

-애자일의 핵심 원칙이 점진적으로 개선하는 방식이기 때문

"실패하더라도 빨리 실패, 성공해도 빨리 성공"

 

-데이터 기반의 의사결정을 하면 성공활률 높힐 수 있음

"각 단계마다 감에 의존하지 말고 데이터를 활용해서 결과의 근거로 제시함으로 객관적인 의사 결정이 가능하다." 

*(예전에는 가장 높은 연봉을 받는 고위직의 의견이 우선되었었는데, 이제는 (구글은) 데이터를 보고 결정한다. 이거임.왜? 그렇게 해야지 성공확률이 높으니까.)

 

-이런 식으로 일을 해야지 추후에 이직을 하거나 취업을 할때도 본인의 프로젝트 경험을 단순히 결과만 보여주면

니라 프레임워크로 설명을 해. 논리적인 사고방식을 평가받을 수 있고 긍정적 평가를 받을 수있다. (실제로 토스에서도 이력서를 작성할때 이런 과정을 통해 작성해달라 요구함)