8주차) 05 - 신규 서비스

사전 이해도 높이기

• 타다 서비스의 이해하기
  • 모빌리티 시장에서 서비스를 운영 중인 타다는 유저의 서비스 이용이 온라인과 오프라인을 넘나드는 O2O 시장으로서의 특징도 가지고 있다.
  • 이로 인해 비즈니스 사이드, 프로덕트 사이드 모두에서 O2O 시장의 특징을 잘 살려서 반영해야 한다.
  • 비즈니스 사이드
    • 라이더/드라이버 양쪽을 고려한 정책 수립 - 양쪽 유저 간 형평성 및 가중치를 둘 유저 사이드 고려가 필요하다.
    • 실제 서비스는 오프라인에서 진행/완료 - 최대한 다양한 발생 가능 케이스를 예측하여 운영 대응 및 지속적인 보강이 필요하다.
    • 처음부터 이를 모두 다 설정하거나 대응하는 것은 비효율적이다. 서비스를 운영하는 중간중간 계속해서 정책을 보완해 나가는 작업이 필요하다.
  • 프로덕트 사이드
    • 한쪽 유저의 액션이 다른 유저의 액션에 영향 - 라이더/드라이버가 각각 앱 내 조작 시 해당 액션이 다른 사이드에서도 영향을 받는 플로우 고려가 필요하다.
    • 정책에 따른 로직 적용 및 구현 - 오프라인에서 벌어지는 각 상황에 대해 사업/운영 정책에 맞춘 제품 동작이 필요하다.
• 호출 예약 서비스 이해하기
  • 서비스 개요 - 미래 시점에 이동이 필요한 경우 타다 탑승을 사전에 예약할 수 있는 서비스
  • 탑승 가능 차량 - 타다 넥스트, 타다 플러스
  • 예약 가능 일시 - 최소 1시간 후 ~ 최대 14일 후

신규 서비스 영역 선정

• Pain Point - 불편한 점
  • 수요 대비 부족했던 차량 공급 수
      1. 이동이 바로 필요한 상황에서 호출 시 배차의 어려움
      2. 배차 후 차량 도착까지 긴 대기 시간
• Unmet Needs - 목표 고객에게 필요한 니즈
  • 동일한 이동 경로를 반복적으로 호출하는 패턴
      1. 당장의 1회성 이동이 필요한 순간뿐만 아니라 동일한 출/도착지를 왕복으로 반복 탑승하는 유저군 확인

신규 서비스 가능성 확인 - 사내 모의 테스트 진행 

• 사내 모의 테스트 목적 
  • 라이더 사이드 
    • 실제 오프라인 상황에서 실시간 호출과 비교 시 느껴지는 차별점
    • 정책적으로 반드시 챙겨야 할 혹은 방지되어야 할 항목 체크
  • 드라이버 사이드
    • 운행 상황/시각/가격 측면에서 실시간 콜과의 차별점
    • 경쟁사 대비 매력으로 어필될 수 있는 포인트 발굴
• 시나리오 설계 - 다양한 운행 시간, 지역, 요금 및 운행 차량 별 테스트 경로 구성
• Tester 모집 - 드라이버 및 사내 임직원 대상 구글폼 신청을 통한 테스터 모집
• Test 시행 - (제품) 임의의 배차 Event 형성, (운영) 실시간 대응 및 진행
• 결과 Wrap-up - (라이더)배차 불안감 해서, (드라이버) 안정적 운행 스케줄

신규 서비스 런칭 준비 시작

• 경쟁사 분석 및 벤치마킹
  • 기획/UX
    • 실제 유저의 입장에서 서비스 경험을 통한 기획 아이데이션
        1. 데스크 기획만으로는 서비스의 엣지포인트, 임팩트를 온전히 전달하기 어렵다.
        2. 경쟁사 서비스를 이용하며 실제 상황에서 유저 인터뷰를 진행할 수도 있으며 장단점 및 채워지지 못한 니즈 발굴이 가능하다.
  • 디자인/UI
    • 유저 친화적인 UI 및 플로우 포인트 발굴
        1. 유저들의 실수 혹은 혼동이 많이 일어나는 부분이 무엇인지에 대한 힌트 획득할 수 있다.
        2. 고민의 과정과 결과물을 카피하는 것은 안되지만 그들이 경험하여 녹여놓은 고민들을 참고로 하여 더해볼 차별점 혹은 더 유리한 포인트는 무엇이 있을지 고민해야 한다.
  • 사업/OP(Operation)
    
    • BM 및 운영 정책 확인
        1. 여러 시나리오 체험 테스트를 통해 운행 가격 등에 대한 BM을 확인
        2. 실제 환경에서 어떠한 운영 정책이 적용되는지 확인

 

프로젝트의 첫 걸음 - 킥 오프(Kick-off)

• MVP 스펙 결정
  
  • 비즈니스 사이드 
    • 유사한 서비스가 이미 존재
        1. 최대한 빠른 출시를 통한 시장 진출 & 유저 확보 필요
  • 프로덕트 사이드
    • 이용을 위한 Main Flow 초점
        1. 서비스 이용 시 갖춰야 할 기본 기능 중심 고려
  • 차별화된 포인트
    
    • 후발 주자로써 유사 서비스와의 경쟁 무기
        1. 타 예약 서비스에 비해 타다 '호출 예약'을 선택해야 하는 이유 제공
        2. 예) 반복되는 일정을 한 번에 예약할 수 있는 '벌크 예약'
  • 최소 스펙 정의
    • 런칭 시 필수 스펙 최소화
        1. 최초 제공 스펙은 유저가 이용을 완료할 수 있는 것에 초점
        2. 이후 고도화 스펙 영역 정의
        3. 예) 예약 일시 변경은 취소 후 재접수, 미매칭 취소 시 자동 재매칭 미제공
• 배경/목적 Align
  • 다양한 팀 간 이해도 및 공동의식 형성
    • 킥오프 회의에는 해당 프로젝트와 관련된 모든 팀이 참여 - 제품(UIUX/개발/QA/데이터), 사업/법무, 마케팅(퍼포먼스/브랜드), 운영/CX
    • 유관부서 모두가 같은 목표를 바라볼 수 있도록 프로젝트의 발단 배경 및 우리가 해결하고자 하는 유저의 Pain point에 대해 충분히 전달하고 공감대 형성
    • 대응 방안 및 이에 대한 검증 지표를 공유하고 의견을 수렴
    • 때로는 FAQ를 미리 준비
• 주요 스펙 Align
  • 주요 사업/운영 정책 공유
    • PM이 러프하게 준비한 시안을 바탕으로 유저가 경험할 주요 플로우에 대해 논의
    • 시각 자료 준비를 통해 모두가 다른 안을 생각하는 것을 방지
    • 때로는 UIUX 디자이너와 사전 협의를 통해 대략의 시안을 미리 준비
    • 각 플로우별 반드시 고려되어야 하는 사항을 명확히 전달 -> 빠르고 효율적인 의사결정
    • 다수의 옵션 중 선택이 필요한 경우 각 옵션 별 객관적 측면의 장단점을 함께 제시 -> 유저친화적인 안으로 선택
  • 사업/운영 측면의 주요 정책 공유
    • 사전 정의가 필요한 서비스 주요 정책을 공유
    • 킥오프 전 PM/사업팀이 사전 확정이 필요한 정책 항목 논의
    • 서비스 운영과 관련 정책의 경우 Business 관련 팀에 R&D 할당 
      예) 운행 요금, 예약 가능 시간대 범위, 페널티/보상 정책 등
    • 제품팀에서는 정해진 정책과 일치하는 개발 구현 집중
    • 서비스 정책 현재 시각으로부터 3시간 후 ~ 최대 14일 후까지 예약 가능
    • 제품 구현 유저가 현재 시각보다 3시간 미만 혹은 14일 이후 시점을 예약 시도하는 경우 해당 액션을 막음
  • 서비스 운영 관련
    • 법무 이슈 검토
        1. 실제 서비스가 운영되는 데 있어 미리 정책 상 미리 법무 검토가 필요한 영역 확인
        2. 특히 타다가 서비스 하는 모빌리티 산업과 같이 규제가 까다로운 곳들은 사전 법무 검토를 반드시 거치며 유저의 사전 동의가 필요한 영역을 꼼꼼히 확인 
  • 제품 구현 관련
    • 업데이트 시나리오 확인
        1. 웹 구현 영역과 같이 서버 배포만으로 가능한 영역과 앱 업데이트가 필요한 영역에 대한 확인 및 배포 시나리오 가늠
        2. 앱 업데이트가 필요한 경우 이전 버전을 사용하는 유저 대응 시나리오 체크
  • 진행 일정 관련
    • 이후 주요 단계 일정 논의
        1. 세부 시나리오까지 고려한 시안 공유 회의 목표 일정 결정
        2. 개발 완료, 필드 테스트, QA, 런칭일 등 주요 마일스톤 일정 정의

신규 서비스 런칭 준비 과정

• 세부 시나리오 및 UI 체크 - 디자인 시안 논의
  • 세부 시나리오 체크
    • Main Flow 외 시나리오 및 미대응 엣지 케이스 논의
        1. 유저가 취할 수 있는 다양한 케이스들에 대한 정리 및 대응 로직 결정
        예) 드라이버 매칭 시도 중 취소, 예약 임박 시간 내 실시간 호출 등
        2. 발생 가능하지만 발생 빈도가 극히 낮을 미대응 케이스 결정
  • 최종 UI 결정
    • 여러 안의 UI 옵션 논의
        1. Product Design 팀에서 짜온 여러 시안 중 최선의 UI 안을 논의 후 선택
        2. 만약 시안만으로 결정이 어려운 경우 필드 테스트 등 실제 구현된 안을 확인 후 결정
  • 개발 일정 재조율
    • 결정된 UI 기반 구현 일정 재산정
        1. UI 확정 전 가안으로 결정했던 개발 일정을 다시 한번 체크
        2. 수정을 위한 버퍼 기간을 고려하여 개발 일정 및 필드 테스트, QA, 일정 산정 

제품 구현 및 UX 체크 - 필드 테스트

• 필드 테스트 목적 
  • 본격적인 QA 돌입 전 기능 구현 점검
      1. 개발 작업 완료 후 본격적인 시나리오 QA 전 주요 플로우 및 시나리오를 중심으로 구현 현황을 점검한다.
  • 실제 상황 대입 시 수정/보충 사항 체크
      1. 기획/UIUX와 실제 현장의 적합도 체크 및 수정/보완이 필요한 포인트 확인
  • 시나리오 설계
    • QA/PM이 테스트 시나리오 정리
    • 유관부서로부터 필요한 체크 포인트 추가 수렴
  • 테스트 조 편성
    • 시나리오 별 1 팀씩 2-3개 편성
    • 기능/스펙을 잘 모르는 동료 섭외
    • 담당 PM/디자이너/개발자/QA 동승
  • Test 시행
    • 시나리오 별 현장 테스트 진행
    • 동승한 담당자가 영상 녹화 및 체크리스트 기반 주요사항 기록
  • 결과 Wrap-up
    • 기능 구현 중 hot fix가 필요한 사항 체크
    • 실제 현장에서 적합하지 않은 기획/UX 개선 포인트 공유 및 대응 스펙 결정

신규 서비스 출시 준비 - 유저 커뮤니케이션 전략

• 커뮤니케이션 주요 목적
  • 신규 기능 런칭 예고
      1. 실제 제품 스펙 배포 전 신규 기능 런칭이 임박했음을 알리며 유저 기대감 유도
  • 단계 별 사용 방법 안내
      1. 새로운 기능, 플로우를 접하는 유저들이 어려움 없이 이용을 완료할 수 있도록 주요 프로세스 안내
  • 주요 유의사항 전달
      1. 기존 실시간 호출과 상이한 주요 이용 정책을 축약하여 전달
  • 주요 활동 Tip 소개 및 이용 유도
      1. 예약 서비스의 특성 상 실시간 호출 이용과 상충되는 상황이 발생 가능
      2. 이때 호출 예약을 이용하기 적절한 상황/환경에 대한 가이드를 콘텐츠화하여 제시
        2-1. (비즈니스 측면) 타다 내에서 실시간 이동 서비스와 예약 이동 서비스가 균형을 이뤄 공존하도록 유도
        2-2. (제품 측면) 상황에 따라 앱 내에서 어떻게 액션을 취해야 할 지 명확히 전달

신규 서비스 모니터링 준비 - 데이터 지표 및 트래킹

• 데이터 모니터링 목적
  • 호출 예약 서비스 성과 측정
      1. 신규 서비스의 유저 반응, 이용도, 목표 지표 달성 여부 등 트래킹
  • 이상 신호 및 가드레일 지표와의 상충 감지
      1. 기존 서비스 라인업 성과 지표와의 카니발라이제이션 방지
      2. 호출 예약 지표 성장으로 인해 실시간 지표의 마이너스 성장이라는 역효과 여부에 대한 모니터링
  • 지표 리스트업
    • 제품/사업 측면에서 필요한 모니터링 지표 선정
    • 지표 정의, 모니터링 사유, 관찰 시점 및 공식 등 정리
  • 데이터팀 협의
    • 각 데이터 지표에 대한 이해도 Align
    • 유저 플로우 및 각 부서 별 니즈 기방, 트래킹 데이터 논의
        1. 제품: 예약 관점
        2. 사업: 운행 관점
  • Dashboard 구성
    • Daily, Weekly, Monthly 등 각 주기별 데이터 트래킹 대시보드 형성
    • 가벼운 시트 형태로 시작 -> 이후 전사 정식 대시보드 편입
  • 사후 분석 주제 선정
    • 트래킹을 통해 목효하는 Data Insight 논의
    • 향후 제품/사업 고도화를 위해 살펴봐야 하는 Data 지표 논의
        1. 호출 예약 콜 특성 파악
        2. 호출 예약 유저 특성 파악
        3. 실시간 호출 대비 가격 효용성 확인

신규 서비스 운영 준비 - 교육자료 및 응대 가이드

• 교육자료 및 응대 가이드
  • CX팀 대상 앱 상세 플로우 & 정책 공유
    • 실제 유저를 응대하는 CX팀은 제품팀 못지않게 서비스 이해도가 높아야 하는 부서
    • 최종 구현 완성본을 토대로 CX팀의 제품 및 정책 이해도를 높인다.
  • 도움말/FAQ 구성
    • 유저와 플랫폼 모두의 응대 효율 증진을 위해 PM이 앱 내 제공될 도움말/FAQ 초안을 작성
    • CX팀에서 최종 항목 구성 및 시각자료와 함께 세부 내용을 완성
  • 페널티/보상 관련 자유도 Align
    • 모든 케이스들을 정책에 담는 것은 현실적으로 어려운 영역이며 특히 오프라인에서 최종 서비스가 운영되는 O2O산업에서 돌발 상황은 빈번히 발생
    • 예상되는 주요 상황 체크 및 발생 시 CX팀의 유연한 응대 범위에 대해 사전 협의를 진행

신규 서비스 런칭 - 후속 대응 및 고도화

• 서비스 오픈
  • 실시간 제품 오류 및 운영 이슈 대응
      1. 서비스 오픈은 출근 이후 혹은 점심시간 이후 등 모두가 이슈 대응이 가능한 시간대 혹은 서비스 오픈과 동시에 수요가 높을 수 있는 시간대로 고려
      2. 오픈 당일 및 해당 주는 실시간으로 제품(개발 구현 상) 오류 및 긴급 대응이 필요한 운영 이슈 발생을 면밀히 체크
• 주요 운영 이슈 대응
  • 긴급 대응/핫픽스 TF 운영
      1. 첫 런칭은 완벽한 스펙을 담기보다는 MVP 최소 스펙 런칭을 지향한다.
      2. PM/서버/백오피스/CX(운영) 인원을 주축으로 긴급 수정 및 대응이 필요한 이슈를 선정하여 작업하는 한시적 조직을 운영
• 고도화 영역 확인
  • 스펙 고도화를 위한 로드맵 구축
      1. PM/사업팀이 주축으로 향후 고도화가 필요한 스펙을 리스트업
      2. 가용 리소스 및 임팩트를 고려한 우선순위 선정, 진행 로드맵을 구체화
• 기타 고려 영역
  • 대고객 메세지 정비
    • 서비스 이용 단계 별 대고객 발송 메시지 점검
        1. 런칭 당시 작성한 Push/SMS 메시지 중 수정 또는 보완이 필요한 영역 체크
          1-1. 기본 수단: Push
          1-2. 보조 수단: SMS/알림톡, Status 변화, 수수료 부과 등 중요 메시지의 경우 보조 발송을 통해 내용 인지 강화
  • 도움말 정비
    • 추가 안내가 필요한 영역 점검
        1. 도움말에 추가되지 않은 인입 빈도가 높은 문의 추가를 통한 CS 효율 증대
        2. 앱 내 플로우 상으로도 더 잘 안내될 수 있는 UI 방안 고려
  • 추가 마케팅 진행
    • 서비스 운영 상황에 따른 추가 마케팅 커뮤니케이션
        1. 런칭 직후: 앱 업데이트 비율 증대에 초점을 맞춘 정보성 성격의 마케팅
        2. 운영 안정화 후: 호출 예약 인지 및 이용 유도에 초점을 맞춘 광고성 성격의 마케팅