오늘의 퀴즈 정리) 비즈니스 방향성 선택 기준, 기획 문서의 논리 구조와 설득력, Framer를 활용한 문제 해결 + 오늘의 피드백

• 서비스 기획 숙련 주차 퀴즈 ▼

• 비즈니스 방향성 선택 기준
• 기획 문서의 논리 구조와 설득력
• Framer를 활용한 문제 해결

+) 오늘의 인사이트 + KPT 회고

++) 오늘의 피드백

1. 비즈니스 방향성 선택 기준
◾사용자/시장/기업 관점
2. 기획 문서의 논리 구조
◾기본 구조
◾가설의 역할
3. Framer와 문제 해결
◾Framer 컴포넌트

 

+) 오늘의 인사이트 / KPT 회고

++) 오늘의 피드백(입문 과제 피드백 + 숙련 과제 관련 질문)

 

활동 내역

• 아티클 카타
  → 아티클 카타) 네이버가 N+스토어에 AI 에이전트 기능을 추가한 이유는?
• 정보처리기사 실기 공부(D+36)...ㄷㄷㄷ

 

---

 

오늘의 퀴즈 정리
-
비즈니스 방향성 선택 기준 + 기획 문서의 논리 구조와 설득력 + Framer를 활용한 문제 해결

 

 

1. 비즈니스 방향성 선택 기준

• PM은 의사결정을 할 때 하나의 관점만 보면 안 된다.
• 보통 아래 3가지 관점을 함께 고려한다.

/	사용자 관점	시장 관점	기업 관점
확인 포인트	사용자가 실제로 원하는 것, 불편한 것	경쟁 상황, 시장 규모, 트렌드	매출, KPI, 회사 목표
키워드	사용자의 문제(Pain Point), 사용자 가치(Value), 사용 의향(User Intent)	시장 성장성, 경쟁사 동향, 시장 진입 타이밍	매출 목표, KPI, 전략적 방향성
예시	사용자가 이 기능을 원하는가?, 실제 문제를 해결하는가?	경쟁사는 어디에 투자하는가?, 시장이 커지고 있는가?	올해 목표가 매출 확대인가?, 신규 고객 확보인가?
→ 사용자 요청이 많다고 무조건 개발하는 것도 아니고, 경쟁사가 한다고 따라가는 것도 아니다. 세 관점을 함께 보고 균형을 잡는 것이 PM의 역할이다.

 

 

2. 기획 문서의 논리 구조

• 기획서는 단순히 해결책을 적는 문서가 아니다.

◾기본 구조

1	2	3	4	5
배경	문제	가설	해결책	기대효과
왜 지금 이 문제가 중요한가	현재 어떤 문제가 있는가	무엇이 원인이라고 생각하는가	어떻게 해결할 것인가	어떤 결과를 기대하는가
예시
모바일 커머스 시장 연 30% 성장	경쟁사 대비 결제 편의성 부족	결제 단계가 복잡해서 이탈이 발생한다	간편결제 도입	MAU 20% 증가

 

◾가설의 역할

• 가설은 결과를 측정하는 단계가 아니다.
  → '이 방향으로 가면 문제가 해결될 것이다'라는 검증 가능한 추정이다(문제 → 해결책을 연결하는 다리 역할)

 

3. Framer와 문제 해결

◾Framer 컴포넌트

활용	재사용	일관성 유지	빠른 수정	프로토타입 제작
목적	같은 UI 반복 사용	디자인 시스템 통일	변경 사항 일괄 반영	실제 서비스처럼 테스트

 

◾활용 순서

• 흐름 : 문제 발견 → 프로토타입 제작 → 테스트 → 수정 → 재검증

1	▶	2	▶	3	▶	4
문제와 사용자 니즈 파악		화면 구성		사용자 테스트		피드백 반영 및 개선

 

---

 

오늘의 인사이트

 

프레이머(Framer)에 대해 강의를 듣고도 잘 몰랐는데(그게 몬데...)

퀴즈를 푸니까 좀 감이 잡히는 느낌이다.

프레이머는 단순히 화면을 예쁘게 만드는 도구가 아니라,

유저의 페인포인트를 어떻게 해결할 수 있을지 검증하기 위한 수단이라고 봐야 한다.

 

오늘 진행한 아티클 카타도 굉장히 흥미로웠는데,

(팀원들도 같은 생각이셨는지 논의 주제가 엄청 많아서 세로스크롤이 장난 아니었다)

네이버 플러스 스토어는 단순히 AI가 유행이라서 기능을 추가한 것이 아니라

기업에서 원하는 가치가 뚜렷했고 모든 곳에 AI 기능을 넣는 대신 선택적으로 주요한 부분에 적용했다.

그리고 베타테스트를 통해 검증 후 본격적으로 반영했다는 점이 뭔가 프로 같았다(당연함).

자신들만의 가드레일을 구축하는 느낌.

(방지책(안전망)을 만드는 게 좀비 아포칼립스에서 바리케이드를 치고,
습격해 오는 좀비의 양과 상태를 확인한 뒤 '토끼자' 싶으면 튀는 것과 비슷한 느낌)

 

공부를 할수록 물음표가 사라지는 게 아니라 오히려 늘어가는 기분이지만,

아마 그 물음표가 줄어드는 순간보다

더 좋은 물음표를 던질 수 있게 되는 순간이 내가 성장하는 시점이 아닐까 싶다.

(지금 겪는 건 아마도 성장통이겠지... 아야 아파요)

 

승관씨 립 어디꺼 쓰시나요 자연스럽네요

 

 

---

 

오늘의 KPT 회고

 

Keep	• Framer를 단순 디자인 툴이 아닌 문제 검증 도구 관점으로 이해하기 시작한 점 • 아티클 카타에서 팀원들과 논의 내용을 자유롭게 주고 받으며 인사이트를 많이 얻은 점
Problem	• 아직도 실제 상황에서 세 관점(사용자·시장·기업)이 충돌할 경우 무엇을 우선해야 하는지 판단 기준이 명확하지 않음(이거 정답은 있는 걸까... 상황에 따라 그때그때 반응해야 하는 걸까) • 역기획 역시 기능의 의도는 어느 정도 추론할 수 있지만, 실제 비즈니스 임팩트까지 연결하는 부분은 경험이 더 필요하다고 느낌 • Framer도 개념은 이해했지만 직접 만들고 검증하는 경험은 부족함
Try	• 역기획 시 기능 분석에서 끝내지 않고 문제 → 전략 → 기대 효과까지 연결해서 추론하는 연습하기 • Framer를 활용해 실제 화면을 만들어보고, 사용자 문제를 해결하기 위한 가설 검증 도구로 사용해보기

 

 

---

 

오늘의 피드백 + Q&A
-
입문 과제 피드백 + 숙련 과제 관련 질문

 

이전 과제 피드백

 

◾잘한 점

• 리뷰 데이터를 단순 나열하지 않고 문제 현상과 서비스 이용에 미치는 영향까지 연결해 정리한 점
• 5 Whys, 로직트리, Impact-Effort 매트릭스를 활용해 문제를 구조적으로 분석한 점
• AS-IS / TO-BE, AARRR, KPI, 예상 리스크까지 연결하며 서비스 기획의 전체 흐름을 학습한 점
• 가독성을 고려하여 문서를 정리한 점
• 핵심 문제를 네이버 플러스 스토어의 비즈니스 방향성과 연결하여 선정한 점

◾보완할 점

• 경쟁사 분석
  • 단순히 공통점과 차이점을 비교하는 것을 넘어,
  • 경쟁사는 같은 문제를 어떻게 해결하고 있는지
  • 우리는 무엇을 참고하거나 차별화할 수 있는지
    → 까지 연결하면 분석의 깊이가 더해질 수 있다는 피드백을 받았다.
  • 또한 스크린샷 등을 활용해 시각적으로 비교하는 방법도 추천받았다.
• KPI 설정 근거
  • 내부 데이터가 없는 상황에서 KPI를 설정할 경우,
    '업계 평균, 벤치마크 사례, 유사 서비스 사례' 등을 출처와 함께 제시하면 신뢰도를 높일 수 있다고 한다.
• 시각자료 활용
  • 텍스트 위주보다는 '와이어프레임 / 화면 캡처 / 플로우' 등을
    적극 활용하면 이해도가 높아질 수 있다는 피드백을 받았다.

◾다음 학습 방향

• 'UT(User Test) / A/B Test 설계 / KPI 검증 방법'등을 학습하여
  '이 기능이 효과가 있었는가?'를 검증하는 방법까지 연결해 보는 연습이 필요하다고 한다.

 

Q&A

 

Q1. 와이어프레임은 어느 정도 수준까지 만들어야 할까?

• PM 입장에서는 디자이너 수준의 목업까지 만들 필요는 없다고 한다.
• 중요한 것은 디자인 완성도가 아니라 기능과 화면 구조를 설명할 수 있는 수준의 스켈레톤 와이어프레임이다.
  또한 레퍼런스를 함께 제시하고, 화면 흐름(플로우)은 반드시 포함하는 것을 추천받았다.
• 이번 과제의 경우에는 와이어프레임보다 페르소나 선정과 데이터 분석에 집중하는 것이 의도에 가까웠다고 한다.

 

Q2. PM 포트폴리오에서는 무엇을 더 강조해야 할까?

• AI 기반 서비스를 직접 기획하는 것보다,
  • AI를 활용해 과제를 디벨롭한 과정
  • AI를 활용한 리서치
  • AI를 활용한 분석
  • 랜딩페이지 제작 및 베타 테스트
  • etc...
    → 문제 해결 과정에서 AI를 활용한 경험을 보여주는 것이 더 강점이 될 수 있다고 한다.

 

Q3. 5 Whys는 꼭 사용해야 할까?

• 필수는 아니다.
• 5 Whys는 문제 현상과 근본 원인을 구분하도록 도와주는 도구일 뿐이며,
  현업에서는 '데이터 분석, 이탈률 분석, 대시보드 지표' 등을 통해 원인을 도출하는 경우도 많다고 한다.
• 중요한 것은 프레임워크 자체가 아니라 문제 현상과 원인을 구분하는 것이다.

 

Q4. 공문서만 다뤄봐서 그런 식으로 작성했는데 너무 딱딱해 보여서 고민이다.

       PRD는 그보다는 조금 더 자유로운 듯한데(노션을 사용한다는 점에서/문서는 당연히 한글인 줄)

       이대로도 괜찮을까?

• 오히려 이해관계자가 많을수록 누구나 이해할 수 있는 언어를 사용하는 것이 중요하다고 한다.
• 개발자만 이해할 수 있는 표현보다는 '짧고 명확하게, 개조식으로, 누구나 이해할 수 있게'
  작성하는 것이 더 좋은 문서에 가깝다는 피드백을 받았다.