피드백 및 인사이트를 활용하여 제품 개발 방향 설정

인사이트를 활용해야 하는 이유

관련 인사이트를 수집하고 그러한 인사이트를 활용하여 아이디어를 구체화하면 제안에 대한 신뢰가 높아집니다. 이를 통해 리소스를 효율적으로 사용하고 가장 큰 영향을 미칠 수 있는 영역에 팀의 노고를 집중하기 위해 노력하는 모습을 보여줄 수 있습니다.

인사이트를 얻으면 고객 요구 및 시장 수요를 중심으로 대화를 나누면서 아이디어를 제품 성과에 다시 연결시킬 수 있습니다. 이를 통해 팀, 고객 및 리더십의 신뢰를 얻고 우수한 제품을 만드는 데 필요한 자율성을 확보할 수 있습니다.

목소리가 크거나 말솜씨가 좋은 사람의 의견에 휩쓸려 우선 순위에 대한 논점이 흐려질 때마다 인사이트에 따라 본론으로 다시 돌아올 수 있습니다.

Jira Product Discovery의 인사이트

Jira Product Discovery에서 인사이트는 모든 아이디어에 꼭 필요한 요소입니다. Jira Product Discovery Chrome 확장 프로그램, Slack 또는 Teams 앱, 또는 파트너가 만든 통합 중 하나를 사용하여 아이디어에 관련 인사이트를 추가하는 습관을 만들어야 합니다.

Jira Product Discovery는 지원, 영업, 조사 및 피드백 관리 솔루션과 함께 사용할 수 있습니다. Jira Product Discovery를 사용하면 아이디어가 중요한 이유, 아이디어의 우선 순위를 지정하는 방법 및 아이디어에 수반되는 요소를 설명하면서 관련 피드백 및 인사이트를 아이디어에 추가할 수 있습니다.

그러면 우선 순위 지정을 위한 토론을 시작할 때 해당 인사이트를 바로 활용할 수 있습니다.

인사이트 수집을 위한 채널 설정

의사 결정에 활용할 수 있는 인사이트가 충분하지 않다면 지금이라도 바로 인사이트를 수집하면 됩니다. 인사이트 데이터를 수집하는 지속적인 프로세스를 마련하면, 이러한 데이터를 구체화하여 모든 제품 결정을 지원하는 데 필요한 인사이트로 전환할 수 있습니다.

이 챕터에서는 고객 및 고객 대면 팀 간의 다이렉트 커뮤니케이션 채널을 설정하고 자체 조사 중에 접하는 데이터를 캡처하는 방법을 살펴봅니다.

인사이트를 수집하려면 다양한 채널을 설정하는 것이 좋습니다.

Jira Product Discovery 팀이 인사이트를 수집하는 방법

Jira Product Discovery를 만드는 전체 프로세스는 인사이트 수집의 영향을 받습니다. 이 섹션의 나머지 부분에서는 Jira Product Discovery 팀이 피드백 채널을 설정하고 이를 활용하여 제품 업무를 결정하는 방법을 자세히 살펴봅니다.

인바운드 피드백에서 인사이트 수집

인바운드 피드백, 즉 제품을 적극적으로 사용하는 사람의 우려 사항, 의견 및 질문 등은 가장 중요한 인사이트 소스 중 하나입니다.

Jira Service Management를 통해 피드백 수집

Jira Product Discovery 팀은 Jira Service Management를 사용하여 고객 및 최종 사용자의 솔직한 피드백을 그대로 전달받도록 합니다.

전용 Slack 채널을 통해 피드백 수집

Slack 및 Teams에 내부 이해 관계자들이 질문하고 제안할 수 있는 전용 채널을 만들었습니다. Atlassian에서 의견을 정리한 후에 Jira Slack 앱을 사용하여 아이디어에 인사이트로 추가합니다.

전용 Jira Product Discovery 프로젝트를 통해 피드백 수집

Jira Product Discovery 팀은 이 방법을 사용하지 않지만 많은 고객이 피드백 접수를 위해 전용 Jira Product Discovery를 설정했습니다.

전용 Jira Product Discovery는 제품 및 제공 백로그와 분리된 전용 공간으로, 여기서 기여자들은 각자 아이디어를 만들고 다른 아이디어에 댓글 및 인사이트를 추가하며 서로의 기여에 투표할 수 있습니다.

전용 프로젝트에 우수 사례를 적용하기에 좋은 방법만 있다면 아주 효과적일 수 있습니다. 그렇지 않은 경우, 크고 작은 요청이 중복되어 길게 나열된 목록이 되어 버립니다.

하지만 신중한 설정을 통해 이해 관계자의 수를 제한하고 관리할 수 있을 정도로만 아이디어를 수집한다면 이 방식은 상당히 효과적이었습니다.

사용자 조사를 통해 인사이트 수집

인바운드 피드백을 활용하면 제품을 개선할 수 있는 전반적인 영역을 잘 파악할 수 있습니다. 하지만 그 자체만으로 제품 결정을 내리기에는 충분하지 않습니다. 특히, 컨텍스트가 부족합니다.

다음과 같은 사용자 피드백 또는 기능 요청 하나만으로 전체 스토리를 구성하는 것은 너무 어려운 일입니다.

• 사용자가 직면한 근본적인 문제
• 사용자의 워크플로에 이 문제가 중요한 정도
• 문제가 제품의 나머지 부분에 미치는 영향
• 다른 해결책으로 문제를 해결할 수 있는지 여부

위 항목과 기타 정보를 통틀어 사용자와 꾸준히 대화를 나누는 것만큼 효과적인 방법은 없습니다.

조사에 적합한 사용자를 모집하는 일은 쉽지 않습니다. 하지만 인바운드 피드백 또는 설문조사 솔루션이 있는 경우, 생산적인 조사 대상이 될 수 있는 사용자를 파악하고 바로 연락하여 채팅을 제안하는 채널로 활용할 수 있습니다.

Dovetail을 통해 사용자 조사

Jira Product Discovery 팀은 대부분 Zoom 미팅을 활용합니다. 모든 직원이 원격으로 근무하며, 고객층이 전 세계에 분포되어 있기 때문입니다. 고객이 Atlassian 채널(앱 내 피드백 위젯 또는 커뮤니티 그룹) 중 하나에 흥미로운 피드백을 남기면 팀에서 고객에게 Calendly 링크를 보내 미팅 일정을 예약할 수 있도록 초대합니다.

인터뷰 대상자의 승인을 받은 후에 해당 미팅을 녹화하여 Dovetail에 업로드합니다. 그런 다음, 중요한 대화 내용을 태그하고 관련 아이디어에 인사이트로 추가할 수 있습니다.

시간이 지나면서 지금의 Jira Product Discovery를 만드는 데 큰 도움을 준 라이트하우스 사용자들을 찾아낼 수 있었습니다.

연구 보고서를 통해 사용자 조사

어떤 주제는 보다 심층적인 사용자 조사가 더 효과적일 수도 있습니다. 다행히도 Atlassian에는 연구 및 인사이트 팀이 있습니다. 이 팀에서는 정밀한 연구 기법을 통해 특정 주제를 심층적으로 연구한 다음, 연구 결과를 인사이트로 요약합니다.

예를 들어, 최근에 한 연구원의 도움으로 Jira Product Discovery 평가자들이 겪는 마찰 지점을 파악할 수 있었습니다. 이 보고서에서 얻은 인사이트를 Jira Product Discovery의 아이디어에 태그했으며, 결과를 바탕으로 평가자들이 앱 내에서 온보딩하는 방식을 재고하고 있습니다.

Pendo를 통해 사용자 설문조사

Jira Product Discovery 팀은 Pendo를 사용하여 세분화 및 제품 사용 데이터를 기반으로 특정 사용자 집단을 대상으로 하는 설문조사를 만듭니다.

월간 CSAT 설문지와 같이 정기적으로 진행되는 설문조사도 있고 특정 질문에 대한 답변을 받기 위해 보내는 일회성 설문조사도 있습니다. 일반적으로 이런 질문은 자칫 잘못하면 제품에 막대한 영향을 미칠 수 있으므로 명확하고 시기적절한 데이터를 활용해야 합니다.

설문조사 결과를 Confluence 페이지에 요약하고 관련 아이디어에 인사이트로 추가합니다.

인사이트 수집을 위한 커뮤니티 그룹 구축

커뮤니티 그룹은 사용자를 모아 피드백을 얻을 수 있는 아주 강력한 방법이 될 수 있습니다. 이 그룹을 활용하여 제품 관련 질문에 답하고 새로운 기능의 얼리 어답터를 모집하며, 공지사항을 전달하고 모범 사례를 공유하는 등 다양한 작업을 수행할 수 있습니다.

Atlassian 커뮤니티 그룹

Jira Product Discovery가 시작된 이래로 Atlassian은 사용자와 직접 소통하기 위한 도구로 Atlassian 커뮤니티의 하위 그룹인 Jira Product Discovery를 활용해 왔습니다. 시간이 지나면서 파워 유저들이 다른 사용자들을 지원하고 제품에 대해 배운 점을 공유하기 시작했으며, Atlassian은 이러한 대화를 통해 많은 것을 배웠습니다.

제품 분석을 통한 인사이트 수집

마지막으로, 인사이트를 평가하고 그에 따른 조치를 취하는 방법을 결정할 때 정성적 사용자 피드백뿐만 아니라 정량적 데이터도 고려하는 것이 중요합니다.

제품 분석은 다음 두 가지 세부 수준에서 인사이트를 제공할 수 있습니다.

1. 이탈률 및 고객 LTV와 같은 성장 메트릭.
   
   예를 들어, 평가자가 활성 사용자로 전환하지 못하고 첫 번째 세션 이후에 이탈하는 것을 발견하면 새 기능 구현을 잠시 중단하고 온보딩 흐름을 살펴봐야 할 가능성이 높습니다.
2. 기능 사용량 및 사용자 행동 데이터.
   
   예를 들어, 특정 기능이 부정적인 피드백을 많이 받았고 데이터에 따르면 많은 사람이 사용하지 않는 것으로 밝혀지는 경우 기능을 유지해야 할지, 아니면 폐기해야 할지를 논의하는 게 좋습니다.

제품 분석 도구를 통한 인사이트 확보

회사마다 사용하는 제품 분석 도구는 당연히 다릅니다. Jira Product Discovery 팀에서는 제푸 분석을 위해 Amplitude 및 Pendo를 모두 사용합니다. 특히, 활용률, 기능의 인기도 및 사용자가 온보딩 흐름과 상호 작용하는 방식을 추적하는 데 이 도구를 사용합니다. 그리고 다시 한번 말하지만, 제품 백로그에서 핵심 인사이트를 아이디어에 추가합니다.

인사이트를 토론하는 습관 만들기

제품 팀은 매일 결정을 내립니다. 최대한 많은 고객 데이터를 기반으로 많은 결정을 내리려면 지속적으로 인사이트 작업을 해야 합니다.

어떤 피드백 및 조사 채널을 사용하든 관계없이 피드백 및 조사 채널이 효과가 있으려면 팀이 지속적으로 인사이트를 수집하고 그에 따른 조치를 취해야 합니다. 팀이 한 달에 한 번만 고객 피드백을 받는다면 적시의 고객 의견을 반영하지 못하고 한 달의 의견을 바탕으로 결정을 내리는 셈입니다.

Teresa Torres가 지속적 탐색 습관에서 공유한 이야기처럼, 인사이트를 바탕으로 제품 의사 결정을 내리면 다음과 같은 많은 이점을 누릴 수 있습니다.

1. 정렬 개선.
   
   팀원이 특정 업무를 하는 이유를 이해하고 사용자의 관심사에 대한 공통된 이해를 확립합니다.
2. 증거 기반의 우선 순위 지정.
   
   팀은 시간 경과에 따라 수집한 인사이트를 기반으로 우선 순위를 지정합니다. 훨씬 더 객관적으로 투자 영역을 결정할 수 있습니다.
3. 더 간단한 로드맵 구축.
   
   간단하게 투자할 곳을 명확히 할 수 있으며 시간이 지남에 따라 수집한 인사이트가 잠재적 투자 영역에 가중치를 부여합니다. 현명한 리소스 할당이 명확해지고 정보에 입각한 방식으로 득과 실을 결정할 수 있습니다.
4. 이해 관계자 참여 향상.
   
   고객의 요구 사항 및 우선 순위에 대한 명확한 설명은 따로 증명할 필요가 없습니다. 팀은 고객의 어려움 및 영향에 대해 논의한 내용을 재구성하여 이해 관계자에게 이 설명을 쉽게 전달할 수 있습니다.

Jira Product Discovery에서 인사이트에 대해 토론

Jira Product Discovery 팀에서는 지속적 탐색을 습관으로 만들기 위해 다음의 두 가지 리추얼을 활용합니다.

• 주간 '피드백 로테이션' 할당:

매주 제품 팀 구성원이 '피드백 로테이션'에 할당됩니다. Jira Product Discovery의 채널을 보고 피드백에 응답하며 관련 인사이트를 아이디어에 추가합니다. 보통 일주일에 걸쳐 반나절 정도 걸립니다.

• 주간 '데이터 배스' 미팅:

이 팀 미팅에서는 그 주의 피드백을 검토하면서 배운 점 및 시사점을 논의합니다. 미팅이 끝나면 공식적으로 '피드백 로테이션' 할당을 다음 제품 관리자에게 넘깁니다.

팀은 이 업무를 지속적으로 해왔기 때문에 다양한 새로운 컨텍스트를 바탕으로 우선 순위에 관한 모든 토론을 할 준비가 되어 있습니다.

많은 고객으로부터 피드백을 받으면 누구의 말을 들어야 합니까?

Atlassian은 300,000곳 이상의 고객사를 보유하고 있습니다. Jira Product Discovery 팀에서만 제품 관련 개별 피드백을 매주 수십 건씩 받습니다. 조치는 고사하고 모든 피드백을 직접 처리하는 건 불가능합니다.

인바운드 사용자 피드백을 통해 사용자가 제품을 사용할 때 직면하는 문제의 유형 및 더 만연한 문제를 파악할 수 있습니다. 이 피드백은 제품 아이디어에 영향을 주지만 팀은 이 피드백만을 기반으로 솔루션을 설계하지 않습니다.

대신 솔루션을 개발, 반복 및 제공하면서 보통 소규모의 전담 사용자 그룹과 협력합니다. 이 사용자 그룹이 제공하는 매우 자세하고 표적화된 피드백을 바탕으로, 해당 사용자 그룹과 협력하여 이들을 위한 제품 경험을 구축합니다.

이 테스트 그룹을 "라이트하우스 사용자"라고 합니다. 경험상 라이트하우스 사용자는 10명으로 충분합니다.

라이트하우스 사용자와 협력하는 이유

경험상 라이트하우스 사용자와 협력하는 것이 한 번에 사용자 수천 명을 만족시키려고 노력하는 것보다 더 효과적입니다.

• 소수의 사용자와 토론한 내용을 기반으로 결정을 내릴 수 있어 더 빨리 움직일 수 있습니다.
  
  결정을 내리기 위해 사용자 1,000명을 대상으로 설문 조사를 할 필요가 없습니다. 라이트하우스 사용자에게 가장 먼저 프로토타입을 이용하게 하여 제품 경험을 조기에 테스트할 수 있습니다. 라이트하우스 사용자는 자신에게 기대하는 바가 무엇인지 잘 알고 있습니다. 다루지 않은 버그 또는 코너 케이스가 있을 수 있습니다.
• 팀은 라이트하우스 사용자와 쌓아 온 친밀한 관계를 통해 문제 및 동기를 파악할 수 있으므로, 컨텍스트에 맞는 풍부한 인사이트를 얻을 수 있습니다.
  
  여러 사용자와 한 번 대화하는 것보다 잘 아는 사용자와 여러 번 대화하는 것이 영향력이 더 클 때가 많습니다.
• 전체 팀은 라이트하우스 사용자를 개별적으로 알고 돕고 싶어 하기 때문에 전체 팀에 긴급성을 불러일으킵니다.
  
  라이트하우스 사용자를 전체 팀에 소개하면 팀에 긴급성을 불러일으키고 책임 의식을 고취할 수 있습니다. 관심 있는 한 사람을 위한 문제 해결이 조사 보고서보다 더 큰 동기를 부여합니다.

라이트하우스 사용자 선택 방법

이 업무 방식을 채택하기로 결정했다면, 누가 라이트하우스 사용자로 적합한지 분명히 파악해야 합니다. 잘못 선택하면 엉뚱한 사용자를 위한 잘못된 제품을 만들게 될 수도 있습니다.

Jira Product Discovery 팀은 시간이 지나면서 라이트하우스 사용자가 다음 특성을 공유한다는 사실을 알게 됐습니다.

✅ 아주 명확한 커뮤니케이터

✅ 목표 고객 세그먼트 내에 속함(팀이 정의에 대해 여전히 반복하고 있는 중에도)

✅ 해결하려는 문제 및 고충의 영향을 많이 받음

✅ 고충을 해결할 새로운 방법을 찾고 있지만 아직 성공하지 못함

✅ 경쟁 앱을 사용하지 않아 기능 복제 관련 토론에 초점을 맞추지 않음

✅ 특정 기능을 찾는 대신 새롭고 다양한 업무 방식에 열린 태도를 보임

✅ 기꺼이 초기 단계 제품 또는 기능을 사용하고 피드백을 공유하며 해결책을 논의함

라이트하우스 사용자와의 협력

팀은 라이트하우스 사용자와의 공동 작업에 모든 것을 쏟아붓습니다. 기본적으로 라이트하우스 사용자를 솔루션의 공동 제작자로 대합니다.

• 피드백 및 질문을 공유할 수 있는 전용 Slack 채널을 마련합니다
• 매달 미팅을 통해 라이트하우스 사용자의 제품, 제품 관리 및 경험에 대해 논의합니다
• 초기 디자인을 공유하고 피드백을 받습니다
• 제품, 경험 및 기능에 대한 얼리 액세스를 제공합니다
• 솔루션을 직접 설계한다면 어떻게 할지 질문합니다

라이트하우스 사용자에 대한 자세한 내용은 Atlassian 커뮤니티의 이 시리즈 게시물을 참조하세요.

다음 단계는 무엇인가요?

제품 팀은 인사이트를 기반으로 모든 결정을 내려 사용자의 문제를 해결하고 삶을 더 편하게 바꾸겠다는 궁극적인 목표에 집중할 수 있습니다.

이 핸드북의 마지막 두 섹션에서는 제품 백로그를 사용하여 다음을 수행하는 방법을 자세히 살펴봅니다.

• 영향을 미칠 수 있는 아이디어의 우선 순위를 지정합니다
• 팀 및 이해 관계자가 협업할 수 있는 로드맵을 만듭니다

Jira Product Discovery 팀이 Jira Product Discovery 및 기타 제품을 사용하여 이 업무를 수행하는 방법에 대한 예시를 살펴보겠습니다.