주요 시사점

• 제품 분석은 사용자 참여 및 행동을 추적하고 분석하여 제품 의사 결정 및 개선에 필요한 정보를 제공합니다.

• 데이터 기반 인사이트는 팀이 기능 사용을 이해하고 변경 사항의 우선 순위를 정하며 "공감 부채"를 상환하는 데 도움이 됩니다.

• 분석 및 정성적 피드백을 함께 사용하면 사용자 요구 사항을 완벽하게 파악할 수 있습니다.

• 제품에 분석 기능을 적용하여, 그 결과를 바탕으로 기능 개발 및 최적화를 진행합니다.

고객의 요구를 이해하는 것이 유용한 제품을 만드는 데 중요하기 때문에 제품 매니저로서 우리는 고객에 대해 더 많이 배울 기회를 모두 놓치지 않습니다. 즉, 고객 인터뷰를 수행하고 설문 조사를 실시하며 제품 내 분석을 검토합니다. 제품 분석을 통해 수집한 데이터는 사용자가 무엇을 하고 싶은지, 제품을 어떻게 사용한다고 생각하는지, 심지어 고객의 제품 사용을 우리가 어떻게 생각하는지가 아니라 사용자가 실제로 제품을 어떻게 사용하는지 알려줍니다.

소프트웨어 개발이 다른 점은(그리고 주택 건축도 확실히 도움이 될 수 있는 부분은) 애자일 방법론의 사용입니다. 애자일을 사용하면 여러 팀이 변화에 신속하게 대응할 수 있습니다. 그렇다면 빈번한 지속적 제공에 기반한 애자일 방법론이 장기적이고 큰 그림을 그리는 계획과 어떻게 공존할 수 있을까요? 하나의 상수가 변화한다는 것을 알면 장기간에 걸쳐 현실적인 예측을 하는 것이 가능할까요?

PM은 다음과 같은 질문을 합니다. "사용자가 매일 제품을 얼마나 오래 사용합니까?", "가장 많이 하는 동작은 무엇입니까?", "어떤 기능이 가장 적게 사용됩니까?"와 같은 질문은 사용자를 이해하는 데 매우 중요하며 사용자 경험을 개선하는 방법에 대한 단서를 제공합니다. 이 게시물에서는 제품 분석의 정의, 사용해야 하는 이유, 사용자를 진정으로 이해하여" "공감 부채"를 상환하는 방법, 분석을 사용하여 새로운 기능 개발을 안내하는 방법을 설명합니다

시작하겠습니다.

제품 분석이란 무엇입니까?

제품 분석을 통해 사용자가 제품 또는 서비스에 참여하는 방식을 분석하는 프로세스입니다. 분석을 통해 제품 팀은 사용자 참여 및 행동 데이터를 추적하고 시각화하며 분석할 수 있습니다. 팀은 이 데이터를 사용하여 제품 또는 서비스를 개선하고 최적화합니다.

사용자가 제품으로 무엇을 하고 있는지 양적으로 이해하려면 첫 번째 단계는 제품 분석을 통해 제품을 계측하는 것입니다. 사용자가 제품에서 수행할 수 있는 모든 작업에 대해 이벤트를 작동하여 기능을 사용하는 사용자 수와 사용 빈도를 집계하여 볼 수 있도록 하는 것이 아이디어입니다. 예를 들어 사용자가 특정 버튼을 클릭한 횟수를 추적하려는 경우 "big-red-button.click"이라는 이벤트를 작동할 수 있습니다. 거기서 작업이 필요한 기능, 가장 중요한 기능을 확인하고 그 정보를 사용하여 변경의 우선 순위를 지정할 수 있습니다.

Atlassian은 누구나 가능한 한 쉽게 데이터를 얻고 자체 쿼리와 보고서를 실행할 수 있도록 노력했습니다. 언급한 서비스를 제공하기 위해 내부적으로 개발된 도구도 일부 사용하지만 Google Analytics와 같은 도구도 시작하는 데 도움이 됩니다. 지금까지 개발자부터 PM, 디자인에 이르기까지 모두가 사용법에 대해 질문하고 우리가 구축하는 것의 영향을 이해하려고 노력했습니다.

“공감 부채”: 가장 새로운 종류의 부채

이 새로운 용어 “공감 부채”를 시도해 봅시다.

제품 내 분석은 두 가지 방법으로 공감 부채를 상환하는 데 도움이 될 수 있습니다. 개념 테스트 및 고객 인터뷰와 같은 활동을 통해 수집된 질적 피드백 및 제품 분석 및 NPS 설문 조사 등을 통해 제품 내에서 수집된 양적 데이터입니다.

예를 들어, Confluence는 현재 상당히 오랫동안 사용되어 왔으며 분석이 거의 또는 전혀 없는 기능이 많습니다. 대부분의 사용자가 Confluence를 사용하는 여정의 시작인 대시보드도 그중 하나입니다. 고객 인터뷰를 통해 대시보드에 대한 피드백을 몇 가지 받았지만 양적 관점에서 사용법을 실제로 이해하는 데 필요한 모든 제품 분석은 없었습니다. 다음과 같이 답이 없는 질문이 많이 있었습니다.

• 대시보드의 사용량은 얼마나 됩니까? 일반적인 Confluence 세션에서 사용자는 대시보드를 몇 번이나 방문합니까?

• 사용자가 실제로 대시보드를 사용하는 용도는 무엇입니까? 모든 업데이트 피드인가요? 인기 피드인가요? 아니면 스페이스로 이동인가요?

• 사용자가 대시보드에서 원하는 것은 무엇입니까? 사용자가 대시보드를 방문한 후 하는 작업을 기반으로 가장 잘 드러나는 항목을 결정할 수 있습니까?

다음은 Confluence에서 가장 많이 방문한 페이지를 변경하기 전에 답변이 필요한 몇 가지 근본적인 질문입니다. 제품 내에 분석이 없거나 변경하려는 특정 기능이 없다면 여러분도 같은 상황이므로 결정을 내릴 때 매우 조심해야 합니다. 이제 공감 부채를 갚아야 할 때입니다.

대시보드 테스트를 통해 대시보드에서 수행하는 가장 일반적인 작업이 "즐겨찾기 페이지"를 보는 것임을 알게 되었습니다. 매우 중요한 발견이었고 초기 가설에 딱히 포함되지 않은 발견이었습니다. 여기서 주요 시사점을 얻을 수 있습니다. 가능한 한 빨리 공감 부채를 상환하세요. 제품에 분석이 없다면 최대한 빨리 추가하고 데이터를 사용하여 제품 결정의 정보로 사용하세요. 그렇지 않으면 어둠 속에서 중요한 결정을 내릴지도 모릅니다. 분석은 거짓말하지 않습니다. 분석은 사용자가 제품으로 무엇을 하는지 정확히 보여주지만 좀 더 깊이 파고들어 분석을 통해 사용자가 실제로 원하는 게 무엇인지 이해해 보세요.

미래가 다가오기 전에 시험해 보기

제품 분석을 추가하면 사용자가 기존 기능을 사용하는 방식을 이해하는 데도 유용할 수 있지만 새로운 기능 및 경험을 테스트하는 데에도 매우 유용합니다. 기능의 원하는 사용량에 대한 명확한 목표가 있다면 제품 분석을 통해 빠르게 실패하고 성공할 때까지 반복한다는 오래된 애자일 주문을 향해 나아갈 수 있습니다.

우리가 사용하는 프로세스는 일반적으로 다음과 같습니다.

• 제품 변경에 대한 명확한 가설 정의 – 예: "댓글 상자의 크기를 늘리면 댓글 추가하기가 5% 증가할 것으로 예상됩니다."

• 가설을 테스트할 수 있도록 필요한 분석 이벤트가 로드된 이 변경 사항을 가능한 가장 저렴하게 구현하도록 구축합니다.

• A/B 테스트에서 일부 고객에게 변경 사항을 배포합니다.

• 결과를 기다립니다.

• 더 복잡한 변경의 경우 분석가의 도움을 받아 결과를 분석하여 변경이 성공했는지 여부를 결정합니다.

대시보드 변경을 위해 각각 다른 사용 사례와 일련의 행동을 홍보하는 매우 "독단적인" 세 개의 대시보드를 디자인했습니다. 이 프로세스를 통해 대시보드를 실행했으며 가설은 다소 복잡했지만 우리에게 정말 잘 작동했습니다. 하지만 새로운 기능을 같은 방식으로 테스트하기 전에 고려해야 할 몇 가지 일반적인 주의 사항이 있습니다(우리도 때로는 어렵게 배웠습니다).

사용자의 말에 귀 기울이기

위에서 언급했듯이 데이터에서 정보를 얻는 것이 좋지만 완전히 데이터 중심이라면 사용자를 위해 만드는 전반적인 경험은 보지 못할 수도 있습니다. 결정을 내릴 때가 됐는데 필요한 모든 데이터가 없다면 데이터에 전적으로 의존하는 것도 약간 문제가 될 수 있습니다.

제품 분석은 제품 또는 특정 기능을 사용하는 방식에 대한 적나라한 현실을 드러내지만 매우 일차원적일 수 있습니다. 제품 분석 데이터를 통해 알고 있다고 생각하는 것을 고객 인터뷰, 개념 테스트 워크숍 및 스파링의 질적 피드백과 결합하면 현재 일어나는 상황을 더 완벽하게 파악할 수 있으므로 가능한 최고의 제품을 만들 수 있습니다.