효과적인 제품 개발을 위해 아이디어의 우선 순위 지정
효과적인 우선 순위 지정 방법을 아는 것은 제품 관리자에게 가장 중요한 스킬 중 하나입니다. 효과적인 우선 순위 지정은 성공적인 제품 팀의 강력한 역량으로, 이를 통해 빠르게 움직이고 가장 영향력 있는 활동에 집중할 수 있습니다.
하지만 우선 순위 지정은 명확하거나 간단한 경우가 거의 없으므로, 제품 관리자가 의도적으로 신중하게 판단해야 합니다. 제품 관리자는 당면한 비즈니스 요구 사항, 장기 전략, 고객 요청, 경쟁 및 변화하는 시장 상황 등 상충하는 우선 순위 및 고려 사항 간의 균형을 맞춰야 합니다.
반대로 우선 순위를 인사이트에 기반하여 지정하고 결과와 연결하지 않으면 악몽이 될 수 있습니다. 논의는 갈등으로 발전하고 합의에 도달하는 명확한 방법이 없으며 직감을 따르거나 목소리가 큰 사람의 의견에 따라 선택을 내립니다.
우선 순위 지정은 예술이자 과학
최상의 결과를 얻으려면 우선 순위를 지정할 때 구조화된 방법 및 질적 고려 사항을 함께 사용하고, 직관적인 의사 결정을 위한 여지도 남겨 둬야 합니다.
RICE 또는 영향 및 노력 비교 행렬 같은 프레임워크는 대화를 구조화하는 데 도움이 될 수 있습니다. 하지만 비즈니스 목표 및 고객 요구 사항에 대한 팀 및 이해 관계자의 지식도 활용해야 합니다. 예를 들어 조사, 사용자 인터뷰 및 인바운드 피드백을 기반으로 합니다. 우선 순위 지정에는 과학적 요소가 있지만, 언제나 약간의 예술적 요소가 필요합니다.
조직마다 우선 순위를 지정하는 방식은 다릅니다. 적합한 접근 방식은 회사 문화, 팀 규모, 제품 성숙도 및 의사 결정을 주도하는 주체(예: 영업 중심의 회사 및 제품 중심의 회사 비교)와 같은 요인에 따라 달라집니다.
제품 개발의 많은 부분이 그러하듯이 우선 순위도 지속적으로 개선해야 합니다(예: 우선 순위를 지정할 대상 및 우선 순위를 지정하는 방법).
- 초기 단계 제품을 작업하고 있다면 즉각적인 고객 요구 사항에 초점을 맞출 가능성이 높습니다.
- 제품이 시장에 적합하다고 판단하면 활성화, 사용자 참여 및 유지, 기술 부채 해결, 그리고 시스템의 규모 확장 준비 등을 고려하기 시작할 것입니다.
- 성숙한 제품의 경우 배포를 우선시하고 프리미엄 기능, 파트너십 및 신제품 출시 같은 새로운 수익원을 모색하는 데 초점을 맞출 수 있습니다.
- 팀 및 회사가 성장함에 따라 우선 순위 지정 프로세스에 영업, 지원, 고객 성공 팀 등을 더 많이 참여시켜야 할 수도 있습니다.
영원히 효과적인 완벽한 방법은 절대 찾을 수 없습니다. 이러한 이유로 Atlassian은 성장 단계에서 회사 및 제품에 무엇이 중요한지 적합한 논의를 할 수 있도록 Jira Product Discovery를 유연한 캔버스처럼 설계했습니다. 똑같은 Jira Product Discovery 프로젝트란 없습니다.
우선 순위 지정 성공을 위한 요소
모든 팀은 고유한 방식으로 우선 순위를 지정하겠지만, 효과적인 우선 순위 지정을 위한 몇 가지 핵심 요소는 여전히 존재합니다. 안타깝게도 많은 팀이 비효율적인 우선 순위 지정으로 인해 목표 달성에 어려움을 겪습니다.
우선 순위를 지정할 때 노력해야 할 사항과 피해야 할 사항은 다음과 같습니다.
노력해야 할 사항 | 피해야 할 사항 |
시간이 지남에 따라 사용자 요청, 영업 기회, 전략적 투자 및 메트릭 변동 요인과 같은 다양한 유형의 투자에 균형을 맞추는 우선 순위 지정 | 결과보다는 새 기능 제공 등 산출물에 지나치게 초점을 맞추는 우선 순위 지정 |
전체 제품 팀과 비즈니스 및 고객 요구에 대한 인사이트를 지닌 모든 이해 관계자를 포함하는 공동 작업 중심의 우선 순위 지정 | 리더십의 지시에 따르거나 제품 관리자가 단독으로 처리하는 우선 순위 지정 |
배운 점에 기반한 지속적 우선 순위 지정 | 로드맵 계획을 위한 한 번의 '대규모' 작업에서 1년에 한 번 우선 순위 지정 |
데이터 및 인사이트를 활용하여 지속적 제품 탐색 관행에서 얻은 정량적 및 정성적 데이터를 기반으로 우선 순위 지정 | 직감에 따르거나 목소리가 큰 고객 및 이해 관계자의 의견에 따라 우선 순위 지정 |
균형 잡힌 제품 투자의 우선 순위 지정
많은 제품 팀에서 우선 순위 지정을 '다음에 제공해야 할 기능'을 결정하는 것으로 생각하는 경우가 많습니다.
이러한 관점은 문제를 부릅니다. 경쟁업체의 방해 같은 외부 요인 및 시장 압력을 제쳐두더라도 이러한 방식의 우선 순위 지정으로 원하는 제품 결과를 얻을 수 없습니다.
처음에는 새 기능을 추가하는 것만으로도 빠르게 행동할 수 있습니다. 하지만 이것은 제품 관리의 쉬운 부분입니다. 어려운 부분은 오랫동안 사용자에게 즐거움을 줄 수 있는 제품을 만드는 것입니다.
단순히 고객이 요구하는 것을 모두 제공하는 것만으로 제품을 성공시킬 수는 없습니다. 예를 들면 다음과 같습니다.
- 활성 사용자의 피드백에만 초점을 맞추면 온보딩에 투자하지 않았기 때문에 평가자가 앱의 가치를 이해하지 못할 수도 있습니다
- 불필요한 기능으로 인해 제품 사용이 어려워질 수 있어 얼리 어답터가 다른 사용자에게 제품을 사용하도록 설득할 수 없습니다
- 기존 기능을 유지하기보다 새 기능을 제공하는 데만 집중했기 때문에 버그 및 안정성 문제로 인해 사용자가 주요 작업을 수행하지 못할 수도 있습니다
이러한 위험을 방지하는 한 가지 방법은 제품 성공의 여러 측면에 따라 제품 로드맵을 버킷으로 나누는 것입니다. 새 기능을 위한 버킷이나 기존 기능을 개선하거나, 안정성에 투자하거나 배포에 집중하는 버킷으로 나눌 수 있습니다.
각 버킷에 선제적으로 투자하세요. 불가피하게 발생하는 위기를 무시하다가 위기가 발생한 후에야 대응하기보다는 각 버킷에 미리 예산을 할당하여 대비해야 합니다.
RUF: 신뢰성, 사용성, 새 기능
새 제품 기능 간에 균형 잡힌 투자를 하고 현재 경험을 개선하며 제품의 엔지니어링 기반을 강화하여 신뢰성을 확보하는 것이 좋습니다.
수많은 Atlassian 팀이 균형 잡힌 투자를 하기 위해 사용하는 프레임워크를 RUF라고 합니다.
RUF = 신뢰성 + 사용성 개선 + 새 기능
RUF 프레임워크를 다음과 같은 피라미드로 생각하세요.

신뢰성 | The first thing users expect from your app is that whenever they open it, and it just works. |
Usability improvements | The longer you’ve worked on a product, the more features it likely has. Feature bloat is the silent killer of many apps. |
New Features + Ideas | With a strong foundation in place, you can add new features. Everyone knows what we’re talking about here 😉 |
The 3 Bucket Planning Guide for prioritizing new ideas
Even when it comes to new product ideas, take a balanced approach to set your product up for success.
🛑 You can’t just build whatever features customers ask for, as you risk only helping your current user base.
🛑 You can’t only focus on improving key business metrics like revenue growth, as you might ignore important customer needs.
🛑 You can’t only ship new revolutionary ideas either, or you put reliability and usability at risk
Adam Nash, former VP product and growth at Dropbox, suggested looking at 3 buckets (source: “the 3 bucket planning guide”):

A view of 3 bucket feature planning in Jira Product Discovery
- Metrics Movers are product initiatives that directly contribute to business goals by improving key metrics: sign-ups, conversion, retention, active users, referrals, revenue, etc. Growth initiatives typically fall in this category.
- Customer Requests are what customers ask for, both net-new features and improvements to current experiences. Addressing these helps keep customers happy, reduce support load, and ensure that your product nails its key jobs.
- Delighters are where your product innovates. These are the features your customers didn’t know they wanted, but can improve their lives by changing how they work. Delighters differentiate you from competition and build a moat around your product.
Allocating budget across investments
It’s important to be intentional in how you invest in each of these buckets. Otherwise, your velocity might drop because your team spends 80% of their time fixing bugs, or the growth of your product slows down, because you’re not thinking strategically. Shipping as many new features as possible is unlikely to fix that.
The right budget allocation for each bucket depends on many things, but in particular the stage of your product: pre-PMF (Product Market Fit), post-PMF, or mature product.
In practice, budget allocation could look like this:
| Pre-PMF | Post-PMF | Mature |
---|---|---|---|
신뢰성 | Pre-PMF 10% | Post-PMF 30% | Mature 50% |
Usability improvements | Pre-PMF 20% | Post-PMF 20% | Mature 20% |
Customer requests and delighters | Pre-PMF 70% | Post-PMF 30% | Mature 10% |
Growth initiatives | Pre-PMF
| Post-PMF 20% | Mature 20% |
Remember, this should never be set in stone. For example, you might decide to invest more in new features for a few months, then go back and focus on UX improvements or addressing technical debt.
But as you allocate and re-allocate, it’s important to keep in mind the different aspects that are required to make your product successful, and to balance your investments over time.
There are different ways to manage these investments: you can have teams dedicated to one or the other bucket, you can make sure that each team has one initiative from each bucket at each time, or you can have each team pick work from each of the buckets in a round-robin fashion. There are pros and cons to each approach but it’s a lot more about delivery planning so we won’t cover them here.
Balancing investments at Jira Product Discovery
Here’s how we configured our investment allocation on the Jira Product Discovery team over a six-month period.
Investments across all squads
We have 4 main themes: pricing and packaging, growth, jobs-to-be-done and engineering initiatives. In each of these themes, we have a number of bets.
These bets are distributed amongst the JPD teams: 5 product squads and 1 engineering squad (Sirius, Horizon, Aurora, Juno, Pulsar, X-flow).
Product squads
Each product squad is required to allocate their time with the following split:
- 60% on product initiatives. For this they create a roadmap with two sections: one for new features, and one for improvements to the current product experience.
- 20% on RtB - Run the Business: on-call, bugs, etc.
- 20% on fixing tech debt
While we don’t strictly enforce this allocation, each team discusses keeping this balance during their sprint planning and monthly reviews. Typically, it does hold true over time.
For product initiatives, we keep a watch on feedback we receive from users and discuss every week with all product managers. We separate the feedback into “Boulders,” XL investments, and “Rocks,” large investments.
We have a separate list for “Pebbles,” small improvements fixing “paper cuts” in the UX. These are difficult to prioritize since you can’t compare their impact to L and XL investments. But, their impact compounds over time. The expectation is that each squad has one Pebble fix in progress at any point in time.
Engineering squads
Each engineering squad has a similar split. But instead of product initiatives they focus on pure engineering projects to improve system resilience and scale.
Setting the stage for productive prioritization discussions
There are many people at your company who have insights into business and customer needs your product should help with.
If you can harness this collective knowledge, you can build more confidence in your product decisions and mitigate the risk of making the wrong bets.
But this is easier said than done. We’ve heard of product teams being swamped with asks from leadership and sales teams, then constantly interrupted with requests for updates: “when is my request going to ship?”
Done right, you can get a lot of value from turning prioritization into a team sport. A collaborative prioritization process creates clarity of mission, vision and purpose, getting teams across the business working towards shared goals.
Here are a few principles to follow for productive, collaborative prioritization.
명확한 기대 설정
Setting expectations is crucial for everyone to collaborate effectively. People must understand what prioritization actually entails, and how they should contribute.
Here are a few key ingredients:
- Everyone’s roles and responsibilities in the conversation
- Shared goals and ways to measure success
- Designated vocabulary and framework for prioritizing
- Established communication channels and feedback loops
역할 및 책임 할당
For prioritization to be a positive experience for everyone, you want to make it clear how they should contribute.
To help with this, we designed Jira Product Discovery around 3 roles: creators, contributors and stakeholders.

Where creators, contributors, and stakeholders fit into the prioritization process.
역할 | Who they are | 책임 |
---|---|---|
작성자 | Who they are The core product team across product, engineering, design, research. | 책임 Drive the product, the prioritization process, and the ideas from beginning to end. |
기여자 | Who they are Points of contact within the sales, support, customer success, marketing and other field teams. | 책임 Participate in the prioritization process and provide key insights: customer requests, support problems, etc. |
이해 관계자 | Who they are The rest of the company, typically separated in 2 roles: leadership, and everyone else. | 책임 Need visibility on priorities, progress and decisions and ways to provide feedback. |
Review priorities continuously for incremental improvement
비효율적이지만 흔히 볼 수 있는 우선 순위 지정 방식은 연 1~2회 이루어지는 '빅뱅' 접근 방식입니다.
이 접근 방식은 팀이 항상 변화하는 요인에 적응할 수 없으므로 효과가 없습니다. 제품은 시장 상황, 새로운 고객 대화, 예상보다 복잡해지는 구현 등에 대응해야 합니다.
'빅뱅' 우선 순위 지정은 각 결정이 매우 큰 영향을 미치는 큰 논의로 이어집니다. 이렇게 하면 압박 및 기대가 발생하므로 우선 순위 지정 토론에서 긴장을 불러일으킬 수 있습니다. 사람들은 엉뚱한 일에 리소스를 많이 투입하게 될 것을 걱정합니다. 지금 내린 결정으로 수개월 동안 그 결과에 얽매이고 싶지 않기 때문입니다.
대신 팀 및 이해 관계자가 함께 우선 순위 지정을 자주 논의할 것을 권장합니다. 다음에 대해 적어도 2주 또는 한 달에 한 번 논의하세요. 매주 조금씩이라도 논의하는 것이 이상적입니다. "무엇을 배웠습니까? 현재 집중하는 것에 따라 변경되는 것이 있습니까?"
이 논의를 주최하도록 제품 백로그 구성
모두가 역할을 명확히 하고 의사 결정을 순조롭게 내리도록 하려면 다음 방식으로 제품 백로그를 구성하는 것이 좋습니다.
- 작성자들이 Jira Product Discovery 프로젝트에 참여하고 있습니다. 작성자는 구성(필드, 보기 등)을 설정하고 아이디어, 보기 및 인사이트를 만들고 관리합니다.
- 기여자들이 프로젝트에 추가되지만 공동 작업 프리미티브는 제한됩니다. 기여자는 투표, 인사이트, 댓글 및 반응을 추가할 수 있습니다.
- 이해 관계자는 프로젝트에 추가되지 않습니다. 대신 작성자들이 읽기 전용 보기를 게시하여 이해 관계자에게 공유합니다.
대상 그룹마다 별도의 보기를 만드는 것이 좋습니다.

Jira Product Discovery에서 다양한 역할에 따른 세 가지 보기.
역할별 보기를 통해 각 그룹은 그룹에 적합한 방식으로 필요한 정보를 얻을 수 있습니다. 제품 팀이 우선 순위를 지정하는 방법, 현재 논의 중인 아이디어 및 기여하는 방법을 즉시 분명하게 알 수 있습니다. 의견이 다르면 생산적인 방법으로 의견을 제시할 채널이 있습니다.
이 접근 방식은 각 대상 그룹이 효과적으로 참여하도록 지원하여 모든 수준에서 공동 작업 및 정렬을 개선합니다.
Jira Product Discovery의 공동 작업 우선 순위 지정 기법
모두가 조건을 명확히 알면 우선 순위 지정이 투명한 공유 프로세스가 됩니다. 그러면 누구나 실제 논의에 참여할 수 있습니다.
Jira Product Discovery의 제품 백로그는 우선 순위 지정을 공동 작업으로 전환하기에 완벽한 공간입니다. 이 섹션에서는 이 대화를 지원하도록 제품 백로그를 구성하는 다양한 방법을 공유합니다.
이 방법은 대부분 1~5등급과 같이 숫자를 사용합니다. 이 모든 방법은 본질적으로 주관적이며 중요한 것은 숫자 뒤에 숨겨진 '이유'입니다. 모두가 각 아이디어의 상대적 우선 순위에 대해 더 쉽게 논의할 수 있도록 같은 방식으로 이해하는 것이 중요합니다. 예를 들어 '많은 노력' 또는 '낮은 영향'으로 간주되는 아이디어에 대해 모두가 같은 정보를 공유해야 합니다.
제약 조건 내에서 사고하도록 유도하는 $10 게임 수행
$10 게임은 제약 조건을 고려하면서 아이디어의 중요도 순위를 매길 수 있는 매력적인 방법입니다.
시간 및 리소스가 무제한이면 제품 팀은 무엇이든 할 수 있습니다. 하지만 실제로는 둘 다 제한적입니다. 바로 이 경우에 $10 게임이 필요합니다. 이 게임은 제품 매니저처럼 생각하는 연습으로, 플레이어가 제품 관리자의 일이 얼마나 힘든지 이해할 수 있습니다!

Jira Product Discovery의 $10 게임.
방법은 간단합니다. 각 참가자는 예산 $10를 받아 가장 중요하다고 생각하는 아이디어에 '지출'합니다. 참가자는 아이디어에 원하는 만큼 베팅할 수 있습니다. 예를 들어 아이디어 2개에 $5를 걸 수도 있고 3개에 $3를 걸 수도 있습니다. 물론 예산이 꼭 $10일 필요는 없습니다.
그런 다음 참가자는 베팅 이유를 설명합니다. 특정 아이디어가 중요하거나 유망하다고 생각한 이유에 대해 설명합니다. 이 접근 방식은 적극적인 참여 및 토론을 장려하므로 모두의 의견을 고려할 수 있습니다.
우선 순위 지정 주기를 시작할 때 $10 게임을 사용해 보고 모두가 어디에 집중하는지 알아보세요. 또는 마지막에 플레이해서 모두가 정렬되어 있는지 확인하세요.
제품 팀 및 엔지니어링 팀 간의 대화에서 영향 대 노력 행렬 사용
영향 대 노력 행렬은 아이디어의 잠재적 비즈니스 영향 및 아이디어를 실현하는 데 드는 노력을 기준으로 아이디어의 우선 순위를 지정합니다.
이 행렬은 제품 매니저 및 엔지니어 간의 대화를 구조화하는 간단하면서도 강력한 방법입니다.
엔지니어들을 초대하여 제공 복잡성에 대한 관점을 공유합니다. 이렇게 하면 매니저는 빠른 성공 또는 대규모 베팅이 가능한지 파악하고 특정 아이디어를 다른 아이디어보다 우선시해야 하는 이유를 정할 수 있습니다.

Jira Product Discovery의 영향 대 노력 행렬.
RICE(도달 범위, 영향, 신뢰도, 노력)를 통한 신뢰 수준 고려
RICE 프레임워크는 아이디어의 우선 순위 지정에 도움이 되는 4가지 고려 사항, 즉 도달 범위, 영향, 신뢰도 및 노력을 사용합니다. 이 중요한 요소를 대부분의 이해 관계자가 이해할 수 있는 방식으로 구성하므로 인기 있는 제품 관리 도구입니다.

대부분의 기여자는 아이디어의 영향, 도달 범위 및 아이디어를 전달하는 데 드는 노력을 평가하는 데 익숙합니다. 하지만 RICE 프레임워크는 대화에 자신감을 불어넣는다는 이점도 있습니다.
제품 팀은 이 아이디어가 좋은 투자라고 확신합니까? 또는 확신을 가지려면 추가 연구 및 제품 또는 기술 검증이 필요합니까?
이렇게 하면 팀은 아이디어가 확실한 선택인 이유 또는 추가 조사가 필요한 이유를 공유할 수 있습니다.

요구 사항과 일치하는 아이디어에 고객을 태그하도록 고객 대면 팀에 요청
Jira Product Discovery를 사용하는 많은 팀이 이 접근 방식을 선택했습니다. 아이디어 목록이 포함된 보기를 구성하여 고객 대면 팀과 공유합니다.
고객이 아이디어 중 하나와 관련된 요구 사항을 공유하면 영업/지원 담당자가 아이디어에 태그를 답니다. 그러면 태그된 고객 수에 따라 각 아이디어에 점수를 매길 수 있습니다.
고객의 중요도가 세그먼트에 따라 다른 경우 제품 팀 및 고객 팀은 고객마다 다른 가중치를 할당하고 싶을 수도 있습니다. 아래 예제에서는 고객을 엔터프라이즈, 중소기업 및 스타트업으로 구분합니다.
이 방법은 매우 간단하면서도 효과적으로 제품 팀 및 고객 대면 팀 간의 생산적인 대화를 지원할 수 있습니다.

회사 목표에 따라 고객 세그먼트에 가중치를 사용합니다.

우선 순위를 지정하기 위해 주요 고객에게 가중치를 할당합니다.
더 화려하게 만들 수도 있지만 적합한 방법 선택하기
팀에서 우선 순위를 논의할 때는 여러 가지 방법을 사용할 수 있습니다.
어떤 방법이 요구에 적합할지 정하는 것은 전적으로 여러분의 몫이지만 일반적으로 방법이 간단할수록 대화가 더 잘 풀립니다.

과한 기법일 수 있는 Weighted Shortest Job First(WSJF).
어떤 팀은 '올바른' 우선 순위 지정 모델을 찾는 데 집착합니다. 하지만 프레임워크는 목적을 위한 수단일 뿐입니다. 그 의도는 시간 및 관심을 지나치게 잡아먹지 않고 목표를 추구하도록 돕는 것입니다. 우선 순위 프레임워크가 아니라 제품을 관리하고 있다는 사실을 잊지 마세요!
각자에게 가장 효과적인 방법 사용
이 모든 방법은 제안일 뿐입니다. Jira Product Discovery 프로젝트는 모두 다릅니다. 각 회사 또는 팀이 서로 다르기 때문입니다. 이 모든 방법은 채널 전반에서 다음에 대한 균형 잡힌 시각을 구축하는 것이 목적입니다.
- 비즈니스 목표
- 잠재 고객이 원하는 사항
- 고객 및 사용자의 요구
- 지원 팀의 업무 부담을 줄이는 방법
- 영업 대화를 지원하는 방법
- 비즈니스 및 제품에 따른 추가 사항
원하는 대로 우선 순위를 지정할 수 있도록 팀 고유의 요구 및 제품을 기반으로 자체 보기 조합을 만드는 것이 좋습니다. 여러분만이 이것을 바탕으로 무엇에 '예'라고 대답하고 무엇에 '아니요'라고 대답할지 결정할 수 있습니다.
이 논의를 통해 로드맵이 도출됩니다.
다음 단계는?
우선 순위는 의사 결정을 원하는 제품 성과와 연결하는 유일한 방법입니다. 효과적인 우선 순위 지정이란 리소스를 책임감 있게 할당하여 제품 팀이 비즈니스 목표를 달성하고 고객 요구에 대응하도록 지원하는 강력한 로드맵을 의미합니다.
이제 이 핸드북의 마지막 부분을 살펴볼 차례입니다. 지금까지 배운 모든 내용을 모아 다음을 수행합니다.
팀 및 이해 관계자가 협업할 수 있는 로드맵을 만듭니다
Jira Product Discovery 팀이 Jira Product Discovery 및 기타 제품을 사용하여 이 업무를 수행하는 방법에 대한 예시를 살펴보겠습니다.
피드백 및 인사이트
인사이트를 제품 개발 프로세스에 통합하여 의사 결정을 향상하고, 고객 요구 사항에 맞춰 정렬하며, 성공적인 결과를 이끌어 내는 방법을 알아보세요.







