Now that we understand the prerequisites for roadmap prioritization, we can walk through how to build a list of roadmap ideas.
現在我們已經了解了路線圖優先排序的前提條件，我們可以開始構建路線圖想法的清單。

As a PM, you likely have a ton of ideas about features you would love to build. However, Anand calls out an important caveat: “Your job is not to generate all the ideas. Your job is to find all the good ideas. PMs who try to do it all alone have worse outcomes.”
作為產品經理，你可能有很多想要開發的功能點子。然而，Anand 提出了一個重要的警告：「你的工作不是要產生所有的點子。你的工作是要找到所有好的點子。那些試圖獨自完成所有事情的產品經理，結果往往較差。」

With that in mind, you can leverage a few different sources for great ideas, including other teams, your own team, and finally, yourself.
考慮到這一點，你可以利用幾個不同的來源來獲取絕佳的點子，包括其他團隊、你自己的團隊，最後是你自己。

As you gather ideas from each of these sources, you want to document them as a problem first—not a solution. You can include potential solutions that might address the issue if they do emerge, but don’t force it. The goal should not be to build out a complete solution at this stage, since it will be better defined through the opportunity validation and design stages of the product development lifecycle.
當你從這些來源收集想法時，首先要將它們記錄為問題，而不是解決方案。如果有可能解決問題的方案浮現，你可以將其納入，但不要強求。在這個階段，目標不應該是構建一個完整的解決方案，因為在產品開發生命週期的機會驗證和設計階段，解決方案會被更好地定義。

You can use the Roadmap Ideas template to keep track of your ideas. 
您可以使用「Roadmap Ideas」範本來追蹤您的想法。

Let’s start with other teams, which can help you avoid over-anchoring on your own ideas at the expense of others. To source ideas from other teams, set up 1:1s [ONE ON ONES] with cross-functional stakeholders and ask,
讓我們從其他團隊開始，這可以幫助你避免過度依賴自己的想法而忽視他人的意見。為了從其他團隊獲取想法，請安排與跨職能利益相關者的一對一會議，並詢問：

“Given the company strategy and goals, what problems are you excited to solve and why?”
「考量到公司的策略和目標，您對解決哪些問題感到興奮，為什麼？」

There are a few do’s and don’ts to keep in mind to get the best input from other teams. Do talk to individuals on teams that are close to the customer. Depending on your company, that might include marketing, sales, or customer support. These individuals can provide you with a quantitative and qualitative view of customer problems that they see firsthand. 
在尋求其他團隊的最佳意見時，有一些注意事項需要記住。應該與那些接近客戶的團隊成員交談。根據公司的不同，這可能包括行銷、銷售或客戶支持部門的成員。這些人可以為您提供他們親眼目睹的客戶問題的定量和定性觀點。

Don’t try to talk to everyone. Asking for input from too many people can place too heavy a burden on that team. In addition, trying to speak to everyone means you haven’t vetted who will have the best input, so you’ll likely get too much input that you can’t use.
不要試圖與每個人交談。向太多人徵求意見可能會給團隊帶來過重的負擔。此外，試圖與每個人交談意味著你尚未篩選出誰能提供最佳意見，因此你可能會得到過多無法使用的意見。

Instead, pick one person to represent that team who will provide a great perspective. As you’re evaluating who to speak to from the team, it might not be the most senior person. Instead, you want to talk to someone who will anchor on specific customer problems. That might be the customer service rep who can share, “I talked to a dozen customers in California and noticed that compliance requirements there are much different than the other states we operate in. We might need to address this issue if we want to expand our footprint there.”
相反地，選擇一位能代表該團隊並提供良好觀點的人。在評估要與團隊中的誰交談時，可能不一定是最資深的人。相反地，你應該與能夠專注於特定客戶問題的人交談。這可能是能夠分享的客服代表：「我與加州的十幾位客戶交談過，發現那裡的合規要求與我們在其他州運營的要求有很大不同。如果我們想在那裡擴展業務，可能需要解決這個問題。」

Do set expectations. If you want to be able to source ideas effectively every time you build or provide input on a roadmap, then you need to avoid burning out your cross-functional partners. That can happen if they give you ideas time after time and don’t see any of those ideas end up in the product, making them feel like their input is not considered. To avoid this scenario, you need to be clear that you are in a phase where you are exploring more ideas than your team can realistically build, and so the final roadmap will reflect only some of these ideas. 
設定期望。如果您希望在每次構建或提供路線圖意見時都能有效地獲取想法，那麼您需要避免讓跨功能合作夥伴感到疲憊不堪。如果他們一次又一次地給您提供想法，卻發現這些想法都沒有出現在產品中，這會讓他們覺得自己的意見沒有被考慮。為了避免這種情況，您需要明確表示您正處於探索比團隊實際能夠構建的更多想法的階段，因此最終的路線圖只會反映其中的一部分想法。

Don’t ask your stakeholders to impose constraints on their ideas. A customer success manager’s job is not to know the cost or technical feasibility of implementing an idea, so be sure to tell folks not to constrain themselves based on these factors. However, you can ask for their view of how they would prioritize their ideas, so you get a sense of what’s most important to their team or function.
不要要求你的利益相關者對他們的想法施加限制。客戶成功經理的工作並不是要了解實現一個想法的成本或技術可行性，因此務必告訴大家不要基於這些因素來限制自己。然而，你可以詢問他們如何優先考慮他們的想法，以便了解對他們的團隊或職能來說，什麼是最重要的。

In addition to speaking to other teams, you should talk with your own team, including your design and engineering counterparts. These individuals can surface interesting problems, insights, and infrastructure decisions for consideration. Similar to speaking with individuals on other teams, it’s critical to set expectations that not every idea will make it onto the roadmap.
除了與其他團隊交流之外，你也應該與自己的團隊溝通，包括設計和工程的同事。這些人可以提出有趣的問題、見解和基礎設施決策供考量。與其他團隊成員交流類似，重要的是要設定期望，並非每個想法都會被納入路線圖。

For example, your engineering counterparts will have an in-depth view of technical debt that they would like to pay down.
例如，你的工程團隊成員將會對他們希望償還的技術債務有深入的了解。

Still, you’re likely not spending most of your team’s capacity on tech debt unless it’s deeply impacting the team’s velocity or blocking the ability to ship new features. Setting expectations and gathering input on what’s most important are essential to these conversations.
然而，除非技術債務嚴重影響團隊的速度或阻礙新功能的發布，否則你可能不會將大部分團隊的精力投入在技術債務上。在這些對話中，設定期望並收集對最重要事項的意見是至關重要的。

Finally, not all of your ideas need to come from others. You can—and should—brainstorm your own ideas about what to build independently of what others have shared with you.
最後，並非所有的想法都需要來自他人。你可以——而且應該——獨立於他人分享的內容之外，自己構思要建構的想法。

Carving out a few hours of deep work for reflection will ensure you have the space to develop your own point of view about what to build. When PMs don’t do this, they run the risk of just building the average of what everyone else has asked for, satisfying no one in the end.
撥出幾個小時進行深度思考，將確保你有空間發展出自己對於該建設什麼的觀點。當產品經理沒有這樣做時，他們就有可能只是建造出大家所要求的平均值，最終無法滿足任何人。

As part of this process, you should lean on the customer data we covered in the previous lesson. Ensuring you actively pursue customer input will help you avoid a scenario where you only build what internal stakeholders want rather than what your target customers want.
在這個過程中，你應該依賴我們在前一課中討論的客戶數據。積極尋求客戶的意見將幫助你避免只建構內部利益相關者想要的，而非目標客戶所需的情況。

Once you’ve gathered your list of ideas from all these sources, clean it for duplicates, noting where there is a positive signal of multiple people generating the same or similar ideas.
當你從所有這些來源收集到你的想法清單後，請清理重複的部分，並注意多個人產生相同或相似想法的正面信號。

Then you’ve completed the divergent step and have an extensive, aggregate list of potential problems to solve.
然後你已經完成了發散步驟，並擁有一份廣泛且綜合的潛在問題清單。

Next, you can begin the convergent phase of whittling the list down to the things you want to build and prioritizing them. We’ll cover how to do this in the next lesson.
接下來，你可以開始進入收斂階段，將清單縮減至你想要建構的項目並進行優先排序。我們將在下一課中討論如何做到這一點。