시작부터 제공까지 아이디어를 제품 결과로 실현
Jira Product Discovery 팀에서는 제품 백로그에서 '아이디어'를 가장 많이 사용합니다. 지속적 검증 및 학습 프로세스를 지원하기 위해 팀은 아이디어를 수명이 긴 개체로 사용합니다. 아이디어는 개발이 시작될 때 백로그에서 나오지만 필요한 영향을 제공할 때까지 탐색 및 제공이 반복되는 동안 지속됩니다.
성공적인 제품 팀은 실험적 사고방식을 채택합니다. 시간이 지날수록 컨텍스트, 사용자 피드백, 사양 및 디자인을 더 많이 추가하여 아이디어를 반복해 나갑니다. 아이디어 수명 주기의 각 단계에서 효과가 있었던 점과 없었던 점을 평가하고, 주요 질문에 답하며, 가정 검증을 통해 투자 영역이 피드백 및 검증과 일치하는지 확인합니다.
큰 아이디어에서 작은 아이디어로
Jira Product Discovery에서 사용하는 개체의 이름은 '아이디어'지만 제품 아이디어, 기회, 문제, 솔루션 등을 나타낼 수 있습니다. 다양한 형태 및 세분화 수준의 아이디어를 담을 수 있도록 제품 백로그를 설계할 수 있습니다.
이 범주를 정의하고 프로세스에 참여하는 모두가 범주에 동의하도록 하는 것이 중요합니다. 그러면 분류 및 비교를 위한 프레임워크 없이도 제품 백로그가 초대형 항목부터 초소형 항목까지 크기가 제각각인 항목으로 뒤섞이는 것을 방지할 수 있습니다.
큰 바위, 바위 및 조약돌: 아이디어를 분류하는 한 가지 방법
Jira Product Discovery 팀에서는 아이디어를 세 가지 수준, 즉 큰 바위, 바위 및 조약돌로 체계화합니다.
큰 바위, 바위 및 조약돌.
- 큰 바위: 잠재적으로 성과가 크지만 불확실성도 높은 대규모 투자
- 예: 대규모 신규 투자, 신제품 요소, 대규모 엔지니어링 프로젝트.
- 바위: 위험이 적은 중간 규모 투자
- 예: 새로운 기능, 새로운 온보딩 실험, 피드백에 따른 재설계
- 조약돌: 보통 간단한 소규모 투자
- 예: 소규모 UX 개선, '페이퍼 컷' 수정
- 예: 소규모 UX 개선, '페이퍼 컷' 수정
팀은 범주가 서로 다른 아이디어에 대해 논의하기 위해 별도의 보기를 사용합니다.
Jira Product Discovery에서 큰 바위 보기.
Jira Product Discovery에서 바위 보기.
Jira Product Discovery에서 조약돌 보기.
아이디어의 특성
Jira Product Discovery에서는 모든 아이디어가 한 줄 요약, 상세한 설명, 고객 피드백과 같은 인사이트, 아이디어 제공을 위한 Jira 티켓의 링크로 완성됩니다.
Jira Product Discovery 내의 아이디어.
Jira Product Discovery 내 아이디어에 대한 제공 패널.
유용성 및 실행 가능성을 최대한 발휘하려면 제품 백로그의 모든 아이디어가 다음 특성을 완비해야 합니다.
특성 | 위험 관리 프로그램이란 무엇입니까? |
|---|---|
| 요약 | 위험 관리 프로그램이란 무엇입니까? 아이디어에 대한 한 줄짜리 요약. |
| 설명 | 위험 관리 프로그램이란 무엇입니까? 기회, 문제 및 솔루션에 대한 더욱 자세한 설명. |
| 필드 | 위험 관리 프로그램이란 무엇입니까? 아이디어의 다양한 측면: 아이디어가 기여하는 목표, 단계, 영향을 미치는 제품 영역, 영향 또는 노력처럼 우선 순위를 지정하는 데 도움이 되는 정보, 사양 또는 디자인에 대한 링크. |
| 인사이트 | 위험 관리 프로그램이란 무엇입니까? 모든 채널을 통해 수집되는 인사이트: 사용자 피드백에서 얻은 주요 배운 점, 고객 대화 및 조사 보고서의 코드 조각, 또는 아이디어가 중요한 이유를 명확히 설명하는 제품 분석 데이터 등. |
| 배포 | 위험 관리 프로그램이란 무엇입니까? 제품 아이디어를 실제로 실현하기 위한 제공 업무에 연결되는 Jira의 제공 티켓 링크(에픽 또는 이니셔티브). |
모든 아이디어에 대해 이 모든 정보를 수집하려면 시간이 걸릴 수 있습니다. 처음에는 고객과의 대화에서 수집한 인사이트처럼 아이디어가 한 줄짜리 요약으로 백로그에 입력될 수 있습니다. 시간이 흐를수록 사용자 인터뷰, 영업 또는 지원 팀의 피드백 또는 회사 전략 변화를 기반으로 더 많은 인사이트를 얻게 됩니다.
사용자 피드백이 담긴 한 줄짜리 요약.
사용자 피드백 및 잠재적 영향 분석 포함.
검증된 솔루션 및 순조롭게 진행 중인 제공 포함.
아이디어를 설명하는 방법은 두 가지가 있습니다. Jira Product Discovery에서 바로 설명하거나 Confluence를 팀의 Jira Product Discovery 프로젝트에 연결하는 것입니다.
Jira Product Discovery에서 아이디어 설명 필드에 요약 또는 정의를 작성합니다. 제공된 템플릿 중 하나를 사용하거나 템플릿을 직접 만들어 아이디어와 관련된 문제, 솔루션, 가설 등을 설명하는 일관된 방식을 입력합니다.
팀에서 Confluence도 사용하는 경우, 아이디어 설명 또는 사용자 지정 하이퍼링크 필드를 사용하여 아이디어를 Confluence 페이지에 연결할 수 있습니다. 이 방법의 이점은 인라인 댓글과 같은 Confluence의 모든 공동 작업 기능을 활용할 수 있다는 점입니다.
설명의 내용 자체는 아이디어의 유형 및 단계에 따라 달라집니다.
아이디어 수명 주기
아이디어의 내용에 못지않게 중요한 것은 시간이 지나면서 아이디어가 진화하는 방식입니다. 각 아이디어가 수명 주기 동안 거치는 단계를 명확하게 정의하는 것이 중요한 이유가 여기에 있습니다. 아이디어 수명 주기의 단계를 설명하는 공통 용어가 있으면 팀 및 이해 관계자와의 모든 대화에서 생산성을 높일 수 있습니다.
Atlassian에서는 발견, 탐색, 제작 및 영향의 네 단계를 사용합니다. Atlassian에서는 모두가 각 단계의 의미를 알고 있습니다. 각 단계에서 팀이 어떤 유형의 업무를 수행하는지, 어떤 질문을 해야 하는지, 그리고 팀에 어떤 유형의 도움이 필요한지 잘 알고 있습니다. 이러한 일관성은 팀 내부뿐 아니라 다른 팀 또는 선임 리더와 논의하는 데에도 적용됩니다.
Jira Product Discovery를 만들 때 Atlassian 팀은 아이디어를 개발, 검증 및 실현하기 위해 이 접근 방식을 사용했습니다. 수명 주기 단계별로 팀이 접근 방식을 실행한 방법을 살펴보겠습니다.
발견, 탐색, 제작, 영향
이 수명 주기로 넘어가기 전에는 모든 아이디어가 주차장에서 시작합니다. 이 단계에서는 일반적으로 아이디어가 나오게 된 이유를 포함한 한 줄짜리 요약에 불과합니다. 이 인사이트는 워크숍, 조사 보고서, 고객과의 토론, 또는 영업 또는 지원 담당자의 피드백 등에서 나온 것일 수 있습니다.
아이디어에 대한 본격적인 작업이 시작되면 다음 네 단계를 따릅니다.
- 발견: 아이디어가 해결할 수 있는 문제 또는 기회, 영향을 미치는 대상 및 중요성에 대해 논의합니다.
- 탐색: 고객 피드백을 통해 검증되는 솔루션을 찾을 때까지 잠재적 솔루션을 구상합니다.
- 제작: 솔루션을 만들고 고객의 요구 사항을 충족할 때까지 반복합니다.
- 영향: 솔루션을 제공하고 결과를 측정하며 원하는 결과를 얻을 때까지 계속 개선합니다.
Jira Product Discovery의 Sirius 팀을 위한 아이디어 단계.
Jira Product Discovery 팀의 아이디어를 아이디어 단계별로 보여주는 보드 보기.
워터폴 모델이 아니기 때문에 단계가 반드시 선형일 필요는 없습니다. 예를 들어, 탐색 단계의 아이디어가 발견 단계로 돌아가는 건 아주 흔한 일입니다. 솔루션을 테스트하면서 문제에 대해 더 많이 알게 되기 때문입니다. 몇 번을 시도해도 적합한 솔루션을 찾지 못하면 일부 아이디어를 포기하게 될 수도 있습니다.
다음 섹션에서는 Jira Product Discovery를 만들 때 Atlassian 팀이 단계를 따른 방식을 살펴보면서 각 단계를 알아보겠습니다.
이 프로세스가 궁금하시면 다음 강연을 시청하여 자세한 내용을 확인하세요.
발견
발견 단계에서는 문제 또는 기회를 검증합니다.
이 단계에서는 보통 고객과의 정성적 인터뷰에 의존합니다. 이 조사를 통해 팀은 아이디어로 실현할 이점 및 결과를 명확히 하고 고객 및 비즈니스에 제공하는 가치로 측정할 수 있습니다. 또한 성공을 측정하는 방법에 대한 가설도 세웁니다.
이 단계의 아이디어를 위해 Jira Product Discovery의 '문제 정의' 템플릿을 사용하거나 직접 만들 수 있습니다.
Jira Product Discovery의 '문제 정의' 템플릿.
발견, 탐색, 제작 및 영향 단계에서 조사 및 고객과의 대화를 통해 배운 점을 아이디어의 인사이트 섹션에 캡처합니다.
Jira Product Discovery의 아이디어를 위한 인사이트 필드.
발견 단계의 실제 모습
Jira Product Discovery를 만들 당시 발견 단계가 어땠는지 살펴보겠습니다. 이 제품의 원래 아이디어 출처는 다음과 같았습니다.
소프트웨어 제공에 Jira를 사용하는 제품 관리자들과의 인터뷰
Atlassian의 자체 조사 및 인사이트 팀과 Gartner 및 Forrester와 같은 분석 회사의 조사 분석
Marty Cagan의 블로그 및 Teresa Torres의 책 등 제품 개발 모범 사례 예시.
이 인사이트를 수집하여 다음과 같은 확신을 얻게 됐습니다.
- PM은 효과적으로 우선 순위를 지정하는 것부터 모두에게 로드맵을 납득시키는 것까지 여러 가지 문제로 어려움을 겪고 있었습니다
- PM은 이러한 고충을 해결하기 위해 Jira를 사용했지만 Jira가 그러한 목적으로 설계되지 않았기 때문에 성공은 제한적이었습니다
- PM은 탐색을 우선하는 사고방식으로 결과를 제공해야 할 시기에 상용 기능과 같은 산출물에 집중하며 제공에만 매달렸습니다
- 제품 관리는 기술 회사를 넘어 핵심 기능으로 자리 잡고 있었습니다. 따라서 Atlassian은 이것이 큰 기회이며 솔루션에 대한 수요가 많을 것으로 생각했습니다.
Jira Product Discovery 방문 페이지.
수요에 관한 가설이 가장 위험한 가정이었기 때문에 이 가설을 검증하는 데 특히 집중했습니다. 가설이 틀렸다면 소수의 회사에서만 구입할 제품을 만드는 상황이었습니다.
그래서 코드 한 줄을 작성하기 전에 제품을 광고하는 웹페이지를 만들었습니다.
결과는 가설을 뒷받침했습니다. 단 2주 만에 3,000명이 대기 명단에 등록했습니다.
살펴보기
탐색 단계에서는 발견 단계에서 식별한 문제 또는 기회에 대한 솔루션을 개념화, 테스트 및 검증합니다.
우리는 많은 제품 아이디어가 실패한다는 사실을 잘 알고 있습니다. 아이디어는 프로세스의 일부일 뿐입니다! 장래성이 떨어지는 아이디어를 더 빠르게 식별하고 좋은 아이디어를 위한 길을 열어줄 수 있도록 Marty Cagan은 제품 관리자가 네 가지 주요 위험을 해결해야 한다고 제안합니다. 파악한 문제 및 기회에 대한 가능한 솔루션을 평가할 때 이 제안을 활용하세요.
- 솔루션이 고객에게 가치가 있습니까? 그렇지 않다면, 예를 들어 이미 더 나은 대안을 이용할 수 있다면 사람들이 그 솔루션을 사용하지 않을 위험이 있습니다.
- 솔루션이 유용하고 직관적입니까? 사용자가 솔루션에서 가치를 얻으려면 액세스 및 사용이 간편해야 합니다. 가치를 얻기까지 장벽이 높으면 사용량이 적은 기능을 제공할 위험이 있습니다.
- 솔루션이 기술적으로 실현 가능합니까? 아이디어에 장래성이 있더라도 엔지니어에게는 아이디어를 실현하는 데 필요한 스킬 및 기술이 있어야 합니다. 그렇지 않으면 불필요하게 리소스를 낭비할 위험이 있습니다.
- 비즈니스 리소스 및 제약 조건 내에서 솔루션이 실행 가능합니까? 적합한 솔루션을 얻으려면 몇 번의 반복이 필요할 수 있습니다. 버려질 아이디어에 시간을 허비할 위험을 방지하려면 기업이 투자할 준비가 되어 있는지 확인해야 합니다
팀의 목표는 최대한 효율적으로 위험을 최소화하고, 직감에 따른 과잉 투자를 하거나 솔루션에 지나친 애정을 쏟는 것을 피하는 것입니다. 기능을 제공한 다음 반복하거나 성능을 조사하다 보면 이런 상황이 종종 발생합니다. 대신, 코드를 작성하기 전에 Figma로 프로토타입을 만들어 고객에게 보여주고 초기 피드백을 받는 것과 같이 노력과 비용이 적게 드는 기술을 사용하세요.
기능을 제공하기로 결정했다면 제한이 많은 라이브 프로토타입을 만들어 소수의 얼리 어답터 그룹과 함께 테스트하고 빠르게 반복하세요. 그러면 모든 코너 케이스를 생각할 필요가 없습니다. 아이디어가 효과가 없는 경우 이유를 훨씬 더 빨리 알 수 있으며, 효과가 있을 때까지 계속 반복하거나 아이디어가 통하지 않을 경우 폐기할 수 있습니다.
불확실성이 큰 영역이 있다면 탐색 단계 중에 기술 스파이크를 수행하세요. 기술 스파이크는 팀의 제약 조건, 기술적으로 실현 가능한 부분 및 기술적으로 복잡한 영역을 이해하는 데 도움을 줄 수 있습니다.
이 단계의 아이디어를 위해 Jira Product Discovery의 '솔루션 정의' 템플릿을 사용하거나 직접 만들 수 있습니다.
Jira Product Discovery의 솔루션 정의 템플릿.
제품 백로그 내에서 각 아이디어와 관련된 모든 문서, 사양 및 디자인을 연결하면 팀 및 이해 관계자와 아이디어를 논의할 때 바로 사용할 수 있습니다. 각 자산(한 페이지 문서, 디자인)을 추적할 수 있도록 각 아이디어에 '하이퍼링크' 필드를 만드는 것이 좋습니다.
방법에 대한 데모를 확인하세요.
탐색 단계 실제 모습
Atlassian은 Jira Product Discovery를 만들 때 다음 기법을 사용하여 고객과 함께 솔루션을 검증했습니다.
먼저, PM에게 다양한 솔루션을 제시하는 슬라이드를 보여주면서 어떤 솔루션에 가장 공감하는지 알아보았습니다. 대화를 통해 고객이 겪는 어려움 및 고객이 중요하게 생각하는 가치에 대해 많은 것을 배우게 되었습니다. 이에 따라 'Jira Product Discovery의 첫 번째 핵심 요소를 우선 순위'로 지정하게 되었습니다.
💡 슬라이드는 이 검증 단계에 매우 유용합니다. 쉽게 만들고 테스트하고 변경할 수 있기 때문입니다.
다음으로 Figma에서 프로토타입을 만들어 고객에게 보여주고 솔루션이 어떻게 도움이 될지 질문했습니다. 처음 시도한 프로토타입은 PM이 이해 관계자 피드백을 사용하여 우선 순위를 지정하도록 돕는 솔루션이었습니다.
PM은 확실히 관심을 보였지만 가치를 얻기 전에 설정에 너무 많은 노력이 든다고 느꼈습니다. 그래서 이 아이디어는 폐기됐습니다.
이렇게 피드백을 여러 차례 수집한 후 오늘날 제품 아이디어를 논의하기 위한 공동 작업 공간인 Jira Product Discovery로 발전한 솔루션을 탐색하게 되었습니다.
이 단계에서 사용자들과의 대화가 크게 바뀌었습니다. 많은 사람이 이 도구가 큰 도움이 될 것 같으니 언제 이용할 수 있는지 문의했습니다. 그 순간 팀이 올바른 방향으로 가고 있음을 깨닫게 되었습니다.
이렇게 피드백을 여러 차례 수집한 후 오늘날 제품 아이디어를 논의하기 위한 공동 작업 공간인 Jira Product Discovery로 발전한 솔루션을 탐색하게 되었습니다.
이 단계에서 사용자들과의 대화가 크게 바뀌었습니다. 많은 사람이 이 도구가 큰 도움이 될 것 같으니 언제 이용할 수 있는지 문의했습니다. 그 순간 팀이 올바른 방향으로 가고 있음을 깨닫게 되었습니다.
제작
제작 단계에서 팀은 탐색 단계에서 결정한 솔루션을 구축 및 검증합니다. 개발 업무 중 대부분이 바로 이 단계에서 이루어집니다.
이 단계의 산출물은 새로운 제품 또는 기능, 또는 기존 경험을 향상하는 개선 사항 등 실제로 도움이 되는 소프트웨어입니다. 즉, 예상한 결과를 제공할 수 있음이 입증되었고, 그 가치를 입증할 만큼 많은 고객이 채택했으며, 모든 고객이 사용할 준비가 되어 있는 제품입니다.
이 단계 또는 탐색 단계 중에 제공이 시작되면 아이디어를 Jira의 제공 티켓에 연결할 수 있습니다(에픽 수준 이상 권장). Jira Product Discovery 내에서 제공 진행률을 추적하고 모든 제품 이니셔티브 및 팀의 진행률을 한눈에 볼 수 있습니다.
Jira에서의 아이디어 및 제공 업무의 관계.
아이디어를 제공하는 데 여러 팀이 참여하여 다양한 Jira 프로젝트에서 작업하는 경우, 모든 제공 티켓을 제품 백로그의 아이디어에 연결할 수 있습니다.
서로 다른 세 개의 Jira 스쿼드에서 제공하는 아이디어.
그러면 JPD 내에서 제공 진행률을 추적하고 모든 제품 이니셔티브 및 팀의 진행률을 한눈에 볼 수 있습니다.
진행 중인 제품 작업의 대시보드.
자세한 내용은 리소스 섹션의 "Jira에서 탐색 및 제공을 연결하는 방법"에 관한 웹 세미나를 참조하세요.
솔루션이 기대한 결과를 즉시 제공할 가능성은 매우 낮다는 점을 기억하세요. 대신, 고객에게 가장 먼저, 자주 제공하고 충분히 좋아질 때까지 계속 반복하세요. 고객과의 대화에서 얻은 인사이트를 배운 점을 바탕으로 아이디어에 계속 추가하세요. 성공을 측정하는 방법은 새로운 기능, 성장 이니셔티브 등 아이디어 유형에 따라 달라집니다. 모두가 이 점을 알고 있고 계획에서 반복이 가능한지 확인하세요.
제작 단계의 실제 모습
Jira Product Discovery를 만들고 제품에 중요한 새 기능을 추가할 때마다 팀은 점점 더 많은 고객 그룹을 대상으로 테스트 및 검증을 했습니다. 이 프로세스에 몇 주가 걸리기도 했고, 몇 달이 걸리기도 했습니다.
| 고객 0명 → 10명 | 팀은 탐색 단계에서 미리 선정한 소수의 고객을 대상으로 반복을 진행했습니다. 고객들과 매우 긴밀하게 협력하여 함께 솔루션을 구체화했습니다. 고객들이 솔루션을 통해 직면한 문제를 해결했다는 확인을 받을 때까지 계속 반복했습니다. |
| 고객 10명 → 100명 | 그 후로, 점진적으로 더 많은 고객에게 솔루션을 이용하게 했습니다. 결과적으로 처음에는 고려하지 않았던 다양한 시나리오를 식별할 수 있었습니다. 그리고 솔루션을 이용하는 활성 고객이 100명이 될 때까지 계속 반복했습니다. |
| 고객 100명 → 1,000명 | 그 후로, 1,000명이 될 때까지 더 많은 고객에게 솔루션을 이용하게 했습니다. 그런 다음 제품 분석, 지원 티켓 및 인바운드 피드백을 통해 사용량 수치를 살펴봤습니다. 조사 결과를 바탕으로 UX를 개선하거나 버그를 수정했습니다. 사용량이 너무 적어서 유용하지 않으면 기능의 검색 가능성을 살펴봤습니다. |
| 일반 공급 | 드디어 지원, 영업 지원, 운영 대시보드, 성능 및 확장성 개선이 모두 준비됐습니다. |
이와 같이 솔루션을 작업할 때는 보통 '라이브 기능 문서'라는 별도의 Confluence 페이지에서 솔루션을 구체화합니다. 팀 미팅 때마다 현재 반복의 범위를 논의하기 위해 열어보는 아주 간단한 페이지입니다. 제공하기 쉬운 기능과 어려운 기능에 대해 더 많이 알아가면서 이 문서를 자주 업데이트합니다. 이 문서는 개별 작업이 아니라 제품 경험에 초점을 맞춥니다. 이를 통해 제품 팀에서 디자인 팀, 엔지니어링 팀에 이르기까지 모든 팀원은 제품 경험에 맞춰 정렬될 수 있습니다.
Jira Product Discovery의 라이브 기능 문서.
영향
제품 모델에서는 모든 것이 결과로 시작하여 결과로 끝납니다. 팀은 결과를 얻을 수 있도록 아이디어의 우선 순위를 지정하고, 제공한 후에는 결과를 향한 진행률을 계속 모니터링합니다. 이 정보를 바탕으로 목표 및 전략을 업데이트하고, 다음 조치의 우선 순위를 지정할 수 있습니다.
솔루션은 제공된 후에도 결코 '완료'되지 않습니다. 기능은 도입하는 순간 제품의 일부가 됩니다. 사용자에게 가치를 제공하고 사용자가 사용하기에 혼란스럽거나 어렵지 않도록 계속 개선해야 합니다. 고객의 요구 사항, 새로운 기능에 대한 의견 및 지원 티켓에 언급하는 빈도를 추적해야 합니다.
영향 단계의 실제 모습
Jira Product Discovery 팀에서는 월간 및 분기별 검토를 통해 팀이 달성한 영향을 계획한 목표와 비교합니다. 결과가 만족스럽고 변화가 거의 없을 때도 있고, 다른 시도를 하기 위해 로드맵을 재설정할 때도 있습니다.
팀이 사용하는 기법이 하나 있습니다. 솔루션을 제공한 후 그에 대응하는 개선 아이디어를 만들어 다음과 같은 인사이트를 수집하는 것입니다.
- 사용자로부터 받은 인바운드 피드백
- 피드백, 설문 조사 및 인터뷰를 통해 기능이 만들어진 목적에 따라 문제를 해결하고 있는지 여부를 알 수 있는 신호.
- 솔루션이 실제로 사용되는지 파악할 수 있는 제품 분석의 사용량 데이터. 솔루션이 사용되지 않는 경우 검색 가능성 문제가 있거나 팀이 계획한 기능에 대한 기대감이 부족한 것일 수 있습니다.
Jira Product Discovery에서 이전에 제공된 아이디어에 대한 고객 피드백을 추적할 수 있는 보기.
팀은 이 데이터를 정기적으로 살펴보고, 각 팀은 기능 개선에 대한 예산을 할당합니다. 새로운 아이디어 및 기존 아이디어에 대한 개선 사항이 각 팀 로드맵에 표시됩니다.
아이디어의 진행률
Jira Product Discovery는 아이디어에 대한 제공 티켓의 진행률을 보여주는 필드 모음을 제공합니다. 하지만 팀은 이것이 이해 관계자에게 진행률을 전달하는 최선의 방법이라고 생각하지는 않습니다. 에픽 작업이 60% 완료되었든 80% 완료되었든 그 수치가 팀의 실제 진행률을 보여주지는 않습니다.
이해 관계자에게 진행률을 더 효과적으로 전달하는 방법이 있습니다. 각 아이디어를 (필드를 통해) '계획대로 진행 중', '위험', '계획에서 벗어남'으로 표시하고, (아이디어의 설명에) 해설을 제공하는 것입니다. 아주 단순한 공동 작업 프리미티브지만, 도움을 구해야 하는 이해 관계자들과 커뮤니케이션하는 데 매우 효과적입니다.
Jira Product Discovery에서 이해 관계자와의 진행률 커뮤니케이션 보기.
진행률 공유 보기에서 한 아이디어에 대한 세부 정보 더 보기.
Atlas 고객이라면 이미 이 접근 방식에 익숙할 것입니다. 리소스 섹션에서 Jira Product Discovery 아이디어를 Atlas 프로젝트와 연결하는 방법에 대한 동영상을 시청하세요. 이 동영상에서는 제공된 Jira 티켓의 백분율로 진행률을 측정하는 아래의 보기보다 더 효과적이고 정확한 방법을 설명합니다.
Jira에서 제공된 티켓별로 진행률을 보여주는 Jira Product Discovery 보기.
티켓 중심 진행률 보기에서 한 아이디어에 대한 세부 정보 더 보기.
다음 단계는 무엇인가요?
아이디어 구상에서부터 검증 및 제공에 이르기까지, 솔루션을 제공하는 수단으로 아이디어를 활용하면 제품 팀은 팀원들을 체계화하고 결과에 집중할 수 있습니다.
이 핸드북의 나머지 부분에서는 제품 백로그를 사용하여 다음을 수행하는 방법을 자세히 설명합니다.
- 피드백 채널을 설정하고 아이디어를 검증하기 위한 인사이트를 수집합니다
- 영향을 미칠 수 있는 아이디어의 우선 순위를 지정합니다
- 팀 및 이해 관계자가 협업할 수 있는 로드맵을 만듭니다
Jira Product Discovery 팀이 Jira Product Discovery 및 기타 제품을 사용하여 이 업무를 수행하는 방법에 대한 예시를 살펴보겠습니다.
제품 백로그
제품 백로그를 효과적으로 관리하여 아이디어의 우선 순위를 지정하고 공동 작업을 강화하며 제품 개발을 추진합니다.
피드백 및 인사이트
인사이트를 제품 개발 프로세스에 통합하여 의사 결정을 향상하고, 고객 요구 사항에 맞춰 정렬하며, 성공적인 결과를 이끌어 내는 방법을 알아보세요.
