[PM부트캠프6기] 0318 Today I learned

오늘은 오전에 스크럼을 진행하면서 페르소나의 여정 단계를 각 팀별로 명확하게 정의하고 3일차 조사를 진행하였다.

이번 3일차에서는 서비스 흐름을 바탕으로, 발생할 수 있는 문제를 사용자/비즈니스/데이터 관점으로 정의해보는 것이었다.

 

정리를 해보면서 나 혼자서 그냥 해결책 제시에 원래 있던 기능들로 해결이 가능한 것만 쓰는 것 같아서 이렇게 하는게 맞나? 싶어서 튜터님께 질문을 하러 갔다. 근데 막상 질문을 정리하고 들어갔는데도 불구하고 내 질문에 빈 부분이 꽤나 있었어서 이해 하시는데 조금 어려움이 있으셨을 것 같다는 생각이...

튜터님의 조언은 '문제 정의를 더 뾰족하게 잡고, 지금 현재 기능으로 그 단계를 해결할 수 있겠지만 최종적으로는 새로운 문제를 정의해서 도출해보는 것도 좋다' 라고 해주셔서 나는 갔다온 후로, Saas PM 으로서 해결책을 제시하되, 마지막 과도기 단계에서는 좀 조사를 해보면서 앞으로의 방향성을 잡아봐도 좋을 것 같아서 그렇게 진행해보았다.

 

1. 업무 파악
   • 행동: 개인용 메신저(카톡) 알림 사이에서 업무 요청 메시지 선별, 이전 대화를 위로 올려보며 업무의 배경과 기한 확인
   • 사용자 관점: ‘카톡 대화 속에 묻힌 업무 내용을 찾느라 시간을 다 쓴다.’, ‘누가, 언제, 왜 시켰는지 찾느라 바쁘다’
   • 비즈니스 관점: 컨텍스트 스위치 비용 - 카톡 알림 확인 후 다시 업무에 몰입하기까지 평균 23분이 낭비됨
   • 데이터 관점: 카톡 메시지 대비 업무 전환 수, 정보 탐색 평균 시간, 재질문 빈도
   • 감정: 😟 막막함
   • 해결책: [소통 채널 분리] 슬랙 도입을 통해 공사 구분 및 주제별 정보 구조화
2. 정보 재가공
   • 행동: 카톡 내 만료된 파일 재요청 및 다운로드, 구글 시트(일정), 워드(회의록)를 오가며 수기 입력, 흩어진 정보를 개인 노트에 다시 취합/정리
   • 사용자 관점: 회의록(워드)을 보며 일정(시트)을 켜는 창 전환의 피로감을 느낌, 중복 작업과 수기 입력 중 발생하는 휴먼 에러 불안감을 느낌.
   • 비즈니스 관점:
     • 중복 작업으로 인한 리소스 낭비
     • 정보의 파편화로 인한 의사결정 지연
     • 수기 입력에 따른 인적 오류 리스크
     • 정보 휘발성으로 인한 히스토리 관리 부재 - 카톡 만료 기간이 지나 파일이 사라질 수 있음.
   • 데이터 관점: 도구 간 복사/붙여넣기 횟수, 정보 업데이트 지연 시간, 파일 재요청 횟수
   • 감정: 😫 피로함
   • 해결책: [데이터 단일화 및 통합 강화] 노션 데이터베이스(DB)를 활용하여 일정/회의록 통합하여, 중복 작업 및 전환 비용 제거
3. 도구 전환 (과도기)
   • 행동: 새로운 협업툴 도입
   • 사용자 관점: 새로운 툴이 생겼으니 전보다는 업무 효율이 올라가겠지?, "과거 데이터가 깨지면 어떡하지?" 하는 막막함.
   • 비즈니스 관점: 초기 온보딩 실패 시 구독료 낭비 및 사용자 이탈 발생 가능.
   • 데이터 관점: 기존 데이터 임포트 성공률, 첫채널/페이지 생성 시간, 초기 이탈률
   • 감정: 🤨 (반신반의)
   • 해결책: [온보딩 퍼널 최적화] 초기 온보딩 가이드 제공, 기존 문서의 노션 임포트 지원
4. 적응 및 활용
   • 행동: 기능 탐색 및 활용, 사용 방식 학습
   • 사용자 관점: 새로운 툴이 좋긴 한데, 배우기 어렵고 귀찮다
   • 비즈니스 관점:
     • 팀 전체의 학습 비용 발생 - 슬랙의 스레드 문화와 노션의 블록 편집 방식 등 서로 다른 두 툴의 사용법을 동시에 익혀야 함
     • 새로운 툴 학습을 위해 업무 외 시간이 할애됨
     • 팀원 간 숙련도 격차로 인한 정보 비대칭 발생.
   • 데이터 관점: 슬랙 스레드 활용 비중, 노션 템플릿 호출 수, 도구 가이드 문서 체류 시간
   • 감정: 🤯 (혼란)
   • 해결책: [그라운드 룰 및 사례 공유] 팀 내 툴 사용 그라운드 룰 수립, 활용 우수 사례 공유
5. 몰입
   • 행동: 슬랙 스레드 활용, 노션 동기화, 스스로 검색을 통해 히스토리 파악, 업무에 집중
   • 사용자 관점:
     • ‘누구에게 물어볼 필요 없이 노션만 보면 현재 진행 상황을 다 알 수 있어 편하다.’
     • ‘슬랙 알림에 휘둘리지 않고 내가 집중해야 할 업무에만 몰입할 수 있는 시간이 늘어났다.’
   • 비즈니스 관점:
     • 운영 효율 극대화 - 불필요한 회의와 반복적인 업무 확인 요청이 감소
     • 팀의 노하우와 히스토리가 노션에 체계적으로 축적되어 신규 입사자 온보딩 비용 절감
   • 데이터 관점: 팀 내 DAU/MAU(활성도), 검색 활용률, 집중 시간 확보 지표
   • 감정: 😎 (만족)
   • 해결책: [정보 가시성 고도화] 알림 최적화 및 노션 대시보드를 통한 실시간 프로젝트 현황 시각화.
6. 과도기
   • 사용자 관점: 업무 편하자고 연동 설정을 시작했는데, 관리자 승인 기다리고 DB 칸 맞추다가 시간을 다 뺏기네?, 결국 연동 과정이 복잡해서 '슬랙 확인 → 노션 타이핑'이라는 기계적인 노동으로 돌아가야 하네..
   • 페인포인트: [설정의 부채 & 유동성 부족] 업무를 편하게 하려고 시작한 연동 설정이 오히려 또 하나의 설정이 됨. 유동적인 업무 변화(DB 수정)를 연동 기능이 따라가지 못해 결국 수동 작업으로 회귀함.
   • 비즈니스 관점: 공식 연동 기능이 있음에도 사용성 문제로 사장됨.
   • 데이터 관점:
     • 평균 설정 소요 시간 (Avg. Setup Time): 연동 시도 시 발생하는 행정적 낭비 시간
     • 데이터 불일치 발생률: 슬랙 합의 내용과 노션 기록이 일치하지 않는 횟수
     • 창 전환 빈도: 정보 동기화를 위해 두 앱 사이를 오가는 물리적 횟수
   • 감정: 😒(회의감)
   • 해결책: [AI 에이전트 선제 제안] 사용자가 수동으로 매핑할 필요 없이, 슬랙 스레드에서 "기한", "담당자", "상태" 관련 대화가 감지되면 AI가 적절한 노션 DB와 컬럼을 스스로 찾아내어 업데이트 승인 버튼을 띄움.

---

[인사이트]

과도기 부분의 페인포인트를 생각해보면서 앞으로의 B2B SaaS PM이 앞으로 제안할 수 있는 방향에 대해서 조사해보았다.

인사이트 1. 설정이 아닌 먼저 제안하는 방향으로
- 현재: 사용자가 연동하는 것을 직접 공부해서 설정 해야하고, 연동 하더라도 노션의 특정 DB와 슬랙 채널을 수동으로 매핑해야한다. 즉 프로젝트마다 바뀌는 DB구조에 맞춰서 매번 설정해야함.
→ 현재 노션 AI 커넥터는 슬랙 내용을 찾아줄 뿐, 슬랙 대화를 보고 노션 DB를 수정하는 액션은 못하고 있다.
- 기능: 사용자가 도구의 기능을 호출하는 것이 아니라, 도구가 대화의 맥락을 읽고 먼저 개입.
→ 즉, 슬랙 대화 내에서 "기한", "마감", "~까지"와 같은 일정 관련 자연어가 감지되면, AI가 즉시 이를 인식하여 노션 프로젝트 일정 DB에 반영할지 묻는 대화형 인터페이스를 띄운다.
- IF 도입이 됐을 때 성과지표: TTV (Time to Value), Data Integrity (정합성), Context Switching Rate, AI Adoption Rate

[ (개인적인) 인사이트 ]
- 문제 정의할 때, 문제를 구체적으로 더 뾰족하게 잡아야한다. 다른 사람이 이해하기 쉽도록.
- 개인적으로 이번 해결책을 제시할 때, 내가 어떤 관점에서 쓰는지의 경계 잡는게 조금 어려워서 해맸던것 같다. 다른 팀원분이 조사하신 것을 보니 노션의 PM으로써 사용자를 바라보며 노션에서 무엇을 해줄 수 있는지를 비즈니스 관점으로도 잘 해주셔서 그것을 보며 나의 부족함을 느꼈음...먼가 초반부터 이러한 관점이 명확했다면 자료 조사와 해결책 내리는 것에서 더 명확하게 낼 수 있지 않았을까...하는 생각.
- 다음에도 이런 기회가 주어진다면 어떤 관점에서 어떻게 해결책을 내야하는지를 빠르게 정의하고 깊게 파고들것.

---

[새롭게 알게된 개념]

1. DAU (Daily Active Users)
: 일간 활성 사용자 수. 하루 동안 우리 서비스에 접속해 '의미 있는 행동'을 한 고유 사용자 수이다. 협업 툴 관점: 오늘 슬랙에 메시지를 남기거나 노션 문서를 편집한 팀원이 몇 명인가?
→ 서비스가 얼마나 일상적으로 사용되는지 보여준다.

2. MAU (Monthly Active Users)
: 월간 활성 사용자 수. 한 달(30일) 동안 한 번이라도 접속한 고유 사용자 수이다. 협업 툴 관점: 이번 달에 우리 팀원 20명 중 슬랙/노션을 한 번이라도 켠 사람이 몇 명인가?
→ 서비스의 전체적인 규모와 사용자 유지력을 보여준다.