Once you have your list of roadmap ideas, it’s time to prioritize them. If you end up with a hundred items on your ideas list, it can be tempting to dive straight in and start ranking ideas from one to one hundred.
一旦你有了產品路線圖的想法清單，就該開始優先排序了。如果你的想法清單上有一百個項目，可能會很想直接開始從一到一百進行排名。

However, this approach gets PMs in trouble when they get to execution because calculating and maintaining the perfect project ranking is a massive undertaking with little value for the business. Anand describes the problem with a ranked project list this way: “Whenever someone has a new idea, you have to compare it to the hundred other things on the list and do a bunch of ROI estimation every time. You’ve essentially created infinite work to say yes or no to people.”
然而，當專案經理進入執行階段時，這種方法會讓他們陷入困境，因為計算和維持完美的專案排名是一項龐大的工作，對業務幾乎沒有價值。Anand 如此描述排名專案清單的問題：「每當有人有新想法時，你必須將其與清單上的其他一百件事進行比較，並每次都進行一堆投資報酬率的估算。你基本上創造了無限的工作來對人們說是或否。」

PMs can sidestep this problem and drive more clarity with an approach that sculpts the project list down significantly and takes a thematic view instead of an individual project view. In other words, roadmaps are NOT an extensive collection of projects. Instead, they are a small collection of themes. The goal of roadmap prioritization is to surface a set of themes that serve as containers for a collection of projects. Anand adds, “Maintaining a perfect global set of projects is not worth the complexity. It’s better to put those projects into containers so you can say this container matters more than that one.”
產品經理可以透過一種方法來避免這個問題，這種方法能夠大幅縮減專案清單，並採取主題性的視角，而非單一專案的視角。換句話說，路線圖並不是一個龐大的專案集合，而是一個小型的主題集合。路線圖優先排序的目標是呈現一組主題，這些主題作為專案集合的容器。Anand 補充道：「維持一個完美的全球專案集合並不值得那樣的複雜性。將這些專案放入容器中，這樣你就可以說這個容器比那個更重要，這樣會更好。」

This approach makes it easier for PMs to manage the influx of new requests they might get after a roadmap has been set. It’s easier to say no to something if it’s not aligned with your top three themes or containers.
這種方法使產品經理在路線圖設定後更容易管理湧入的新請求。如果某件事不符合您的前三大主題或範疇，拒絕它會更容易。

This approach requires a five-step process: filter the obvious no’s, group into themes, rank themes, rank ideas within those themes, and finalize the roadmap. We’ll cover each of these steps in detail in this lesson. In the next lesson, we’ll demonstrate what this looks like in practice with a case study from Anand’s time at Gusto. [GUST-O, NOT GOOST-O]
這種方法需要五個步驟：篩選出明顯不合適的項目、將項目分組為主題、對主題進行排序、在這些主題內對想法進行排序，並最終確定路線圖。我們將在本課中詳細介紹這些步驟。在下一課中，我們將通過 Anand 在 Gusto 的案例研究來展示這在實踐中的樣子。[GUST-O，不是 GOOST-O]

As an early-career PM, building a roadmap might or might not be something you own. Regardless, understanding and starting to think about how it's done can hone your decision-making skills. Even if you don’t own this at your current company, you can still do this exercise to develop your intuition. You can tell your manager that you want to practice roadmap prioritization by doing it on your own, comparing it to the actual product roadmap, and then discussing why it's different as a development exercise.
作為一名職業生涯初期的產品經理，制定產品路線圖可能是你的職責，也可能不是。無論如何，理解並開始思考如何制定路線圖可以磨練你的決策能力。即使在你目前的公司中這不是你的職責，你仍然可以通過這個練習來培養你的直覺。你可以告訴你的經理，你想通過自己制定路線圖來練習優先排序，然後將其與實際的產品路線圖進行比較，並作為一種發展練習來討論其中的差異。

Let’s start with filtering the obvious no’s. This is your first pass at whittling down the list to your top priorities by removing anything that doesn’t align with the company goals, customer needs, or team goals.
首先，讓我們過濾掉顯而易見的否定項目。這是您第一次篩選清單，通過移除任何不符合公司目標、客戶需求或團隊目標的項目，來縮小至您的首要優先事項。

Anand shares, “This first pass can eliminate a significant proportion of the potential ideas, sometimes as much as 75%.”
阿南德分享道：「這第一輪篩選可以淘汰掉大量潛在的想法，有時甚至高達 75%。」

To do this, use your prerequisites as filtering criteria. Remove anything that doesn’t align with the current company or team goals or customer needs.
為此，請將您的先決條件作為篩選標準。刪除任何不符合當前公司或團隊目標或客戶需求的內容。

With your significantly shorter list of ideas, you want to group your project ideas into themes. As you’re reviewing the list, you should begin to be able to see themes emerging. 
在大幅縮短的想法清單中，您需要將專案想法歸類為不同的主題。在檢視清單時，您應該開始能夠看到主題的浮現。

A few examples of themes are specific customer problems or customer segments, metrics such as engagement, retention, acquisition, conversion, monetization, or pricing, or certain aspects or surfaces of the product, such as onboarding or admin features.
一些主題的例子包括特定的客戶問題或客戶群體，指標如參與度、留存率、獲取率、轉換率、貨幣化或定價，或是產品的某些方面或界面，例如上手引導或管理功能。

You can apply this concept to your own list by naming the specific themes you see and grouping ideas into those themes.
您可以將這個概念應用到您自己的清單中，為您看到的特定主題命名，並將想法歸入這些主題中。

Next, rank your themes based on which you believe are most critical to the customer or business value. Share your list with your manager, product lead, and others for their opinions and input.
接下來，根據您認為對客戶或業務價值最重要的程度來排列您的主題。將您的清單與經理、產品負責人及其他人分享，以獲取他們的意見和建議。

At the end of this process, you should have three top themes in ranked order—or a compelling reason why you have more than three. You should also have qualitative explanations and quantitative indicators for why you have ranked them in this priority order.
在這個過程結束時，你應該有三個按順序排列的主要主題，或者有一個令人信服的理由說明為什麼會有超過三個。你還應該有質性的解釋和量化的指標來說明為什麼你會以這個優先順序排列它們。

Here are some indicators that things are looking good at this stage. The themes should be internally consistent with themes you learned in your prerequisites and from other teams. For instance, there is an issue if you’re all in on SMB, while sales is all in on enterprise. And where possible, themes should generally be mutually exclusive. While not always possible, this is a good sign.
在這個階段，有一些指標顯示情況良好。這些主題應該與你在先修課程和其他團隊中學到的主題內部一致。例如，如果你們全力投入中小企業，而銷售部門全力投入企業客戶，那就出現了問題。而且在可能的情況下，主題應該大致互不重疊。雖然並非總是可能，但這是一個好的跡象。

Some indicators that things are off base are if there is strong or significant disagreement when sharing with your manager, product lead, head of product, or other teams. It’s also a red flag if you get questions about your assumptions or reasoning, or if something comes up that you didn’t think about or can't prove with qualitative or quantitative data.
當你與經理、產品負責人、產品主管或其他團隊分享時，如果出現強烈或顯著的分歧，這可能是事情不對勁的指標。如果有人對你的假設或推理提出質疑，或者出現了你未曾考慮或無法用質性或量化數據證明的問題，這也是一個警訊。

Once you have your top three themes, you can rank the ideas in those containers based on your estimate of which ones have the highest potential for impact aligned with the prerequisites. For any idea that may take more than a roadmap cycle to build, you should focus on creating a feasible milestone for the end of the roadmap cycle.
一旦你確定了前三個主題，你可以根據對其影響潛力的估計，將這些主題中的想法進行排序，並確保它們符合先決條件。對於任何可能需要超過一個路線圖週期才能完成的想法，你應該專注於為路線圖週期的結束創建一個可行的里程碑。

In the last step, you are finalizing what is on the roadmap for the given period of time. You likely have more ideas than you can deliver within your prioritized set of themes, so you need to decide where the cut-off point is for what you can deliver.
在最後一步中，您正在確定在給定時間內的路線圖內容。您可能擁有比優先主題集中更多的想法，因此您需要決定可以交付的截止點。

There are two ways to do this: by priority or by commitment. The difference between these two scenarios is how hard your deadline is. In the absence of hard deadlines, you are in a priority-driven scenario.
有兩種方式可以做到這一點：按優先順序或按承諾。這兩種情況的區別在於你的截止日期有多緊迫。在沒有緊迫截止日期的情況下，你處於一個以優先順序為導向的情境。

If there are hard deadlines, you are in a commitment-driven scenario. These deadlines might exist for several reasons. Maybe the company made a PR announcement or a commitment to enterprise clients. Deadlines might also emerge as companies look to take advantage of seasonal events like tax season, the holidays, or a big industry conference.
如果有嚴格的截止日期，那麼你處於一個承諾驅動的情境中。這些截止日期可能因多種原因而存在。也許公司發佈了公關公告或對企業客戶做出了承諾。截止日期也可能因公司希望利用季節性事件，如報稅季節、假期或大型行業會議而出現。

Depending on which scenario applies to you, your approach to picking a cutoff point will differ.
根據適用於你的情況，你選擇截止點的方法會有所不同。

In the priority-driven scenario, your goal is to be slightly over-subscribed. Instead of spending too much time estimating and planning in a world that will likely continue to evolve and change, you want to set priorities with enough work to continue in case the team finishes early.
在以優先順序為導向的情境中，你的目標是略微超出預期。與其在一個可能持續演變和改變的世界中花費過多時間進行估算和規劃，不如設定優先順序，確保有足夠的工作量以便在團隊提前完成時能夠繼續進行。

Anand’s rule of thumb is to be over-subscribed by about ⅓. So if you’re doing a quarterly roadmap, you want to be 1-2 sprints (or 2-4 weeks) over-subscribed. If the team has 10 people x 3 [TIMES THREE] months x 2 [TIMES TWO] sprints per month, they have the capacity for 60 sprints total worth of work. So, in this case, the roadmap should plan for around 80 sprints worth of work.
阿南德的經驗法則是超額訂閱約三分之一。因此，如果您正在制定季度路線圖，您希望超額訂閱 1-2 個衝刺（或 2-4 週）。如果團隊有 10 人 x 3 個月 x 每月 2 次衝刺，他們總共可以承擔 60 次衝刺的工作量。因此，在這種情況下，路線圖應該計劃大約 80 次衝刺的工作量。

This is where collaboration with your engineering and design teams becomes essential to ensure that you’ve worked with counterparts to get reasonable estimates. It also helps you get buy-in when you actually begin executing the work through sprints and build cycles.
在這裡，與工程和設計團隊的合作變得至關重要，以確保您已與對應的團隊合作獲得合理的估算。這也有助於您在實際開始通過衝刺和構建週期執行工作時獲得支持。

Anand says it typically takes him a half day, or at most a day, of working with engineering managers to sense check and estimate how long various ideas and initiatives might take.
阿南德說，他通常需要半天，最多一天的時間，與工程經理們一起工作，以檢查和估算各種想法和計劃可能需要的時間。

In the commitment-driven scenario, your goal is to be under-subscribed. This gives you a buffer to handle emerging issues while delivering on time. This is much more of a waterfall planning process, where you want to reverse-engineer from a specific launch date to ensure you can complete everything required.
在承諾驅動的情境中，你的目標是保持低於需求量。這樣可以讓你有緩衝空間來處理突發問題，同時按時交付。這更像是一種瀑布式的規劃過程，你需要從特定的發佈日期逆向推算，以確保能完成所有必要的工作。

Anand shares, “In the commitment paradigm, you want high confidence that you do not have enough work to do. This is different than the priority paradigm, where you want low confidence that you have too much work.”
阿南德分享道：「在承諾模式中，你希望能高度確信自己沒有太多工作要做。這與優先模式不同，在優先模式中，你希望能低度確信自己有太多工作。」

Dealing with dependencies and constraints becomes much more critical in this scenario, so you need to pull forward a lot more of the product development lifecycle work of opportunity validation and design.
在這種情況下，處理依賴性和限制變得更加關鍵，因此你需要提前進行更多的產品開發生命周期工作，包括機會驗證和設計。

For any project that must get done, you want to understand how many sprints it will take and how many people you’ll need. Collaboration with your engineering and design teams is even more essential to get reasonable estimates.
對於任何必須完成的專案，你需要了解需要多少個衝刺週期以及需要多少人手。與工程和設計團隊的合作更加重要，以獲得合理的估算。

Ideally, you should have finished this work for major ideas before going into planning because this helps you better scope and estimate with more accuracy.
理想情況下，你應該在進入規劃階段之前完成這項工作，因為這有助於你更準確地範圍和估算。

When considering how much to under-subscribe, you can reverse the rule you use for priority-driven scenarios and under-plan by about 30%. However, you might increase or decrease this amount by 5-10% based on any of the following factors.
在考慮應該低估多少時，你可以反向使用優先驅動情境中的規則，並低估約 30%。然而，根據以下任何因素，你可能會增加或減少這個數量 5-10%。

First, the criticality of meeting that deadline for the business. If you think the company will completely miss its revenue forecast if you don’t finish your roadmap before tax season, for example, you’re going to want more buffer time. If the deadline exists because of internal factors like a PR announcement, this is less critical.
首先，達成該截止日期對於業務的重要性。如果你認為公司在稅季前未完成路線圖會完全錯過其收入預測，例如，你會希望有更多的緩衝時間。如果截止日期是因為內部因素如公關公告而存在，那麼這就不那麼重要。

The second factor is roadmap complexity. If the work requires a massive team with lots of interdependencies between team members, then you want additional buffer time. If there are fewer dependencies or complexities, you can add more initiatives to your roadmap.
第二個因素是路線圖的複雜性。如果工作需要一個龐大的團隊，且團隊成員之間有許多相互依賴的關係，那麼你需要額外的緩衝時間。如果依賴性或複雜性較少，你可以在路線圖中增加更多的計劃。

The third factor is uncertainty. If the team is undertaking new kinds of work for the first time or it requires skilling up in new areas, you’ll want additional buffer time to account for these unknowns. If the plan requires work that’s similar to tasks the team has executed time and time again, you can increase the number of items in your roadmap.
第三個因素是不確定性。如果團隊首次承擔新類型的工作，或需要在新領域提升技能，你會希望有額外的緩衝時間來應對這些未知因素。如果計劃中的工作與團隊過去反覆執行的任務相似，你可以增加路線圖中的項目數量。

So now we’ve covered the five-step process to get to your final roadmap. In the next lesson, we’ll show what this looks like in practice with a case study from Gusto.
現在我們已經介紹了完成最終路線圖的五個步驟。在下一課中，我們將通過 Gusto 的案例研究展示這在實踐中的樣子。