PM 要不要做{某種工作}？ The Responsibilities of a Product Manager
(English below.)
Product Manager 的職責範圍是一個經常被拿出來探討，但總也沒有標準答案的話題。每當被問到「PM 要不要做某種工作」時，我的回答都得走向 it depends。
為什麼會這樣說呢？先來看看 PM 在產品開發過程中扮演的角色。
核心任務與協作夥伴
個人認為 PM 最核心、也相對獨特的任務是「選題」（不是開票作會議紀錄喬資源跟當鬧鐘，大家遲早會叫 AI 去做這些事的）。這包含了探索假設、尋找解決方案，以滿足市場需求並為公司獲取應得的利益。為了做好這件事，與利害關係人的溝通協調也是不可或缺的。
選題是一件十分複雜的事情，能否選到發大財的題目還是有不少時運成分在。在選題的過程中，市場研究的部分「可能」會有其他角色，如商業分析師或行銷人員的協助。而當選定了要做的事情後，細緻的設計與規劃則「可能」會有產品設計師、UX 設計師、系統分析師等人員的參與。
開發和程式上線通常就不太會要求 PM 動手了，不過像是 App 上架這種形式的「上線」，其中涉及的一些資訊其實與行銷推廣相關，這部分「可能」會有行銷人員支援。產品推出後，收客戶意見、分析用戶使用情況等等，「可能」會有產品設計、客服部門、BI 等單位的同事提供幫助。
「可能」
既然都說是「可能」有，那當然也很可能就沒有。當缺乏這些協力人員時，這些工作好像蠻自然地落到 PM 的肩上，畢竟你（號稱）是這個產品的 Owner 嘛！現實面上考慮到同樣一段時間的實際消耗金額，我的菜鳥時期也很甘願地做了一陣子訂點心啥的庶務，總是要有人做的。
上面都沒提到專案管理的部分。其實在我看來，如果團隊能夠實現自管理，那麼這類工作應該由多人共同承擔（親身經歷過就一試難忘）。但這還要看團隊成員，尤其是主管，能否接受這樣的工作方式。如果遇到比較在意細節的管理者（就是，跟枝節管理一線之隔的那種），大概八成還是會希望有個人一個個去確認。
另外上線前橫豎 PM 都好歹要玩一下… 啊這樣不然我們缺 QA，也你來做好了。
到底要會什麼、該做什麼？
成為一個合格的 PM 需要具備哪些能力有各家版本的說法，搜尋「PM 技能」就有一堆。每篇文章列出的內容都多少反映了作者所偏重的領域，比方說在我目前比較常用的 PM Wheel 這個模型裡，「敏捷能力」就被獨特地列為了一項必備技能。
所有在講產品經理能力的文多少會提到「定義要做什麼事情的能力」，也就是前面稱的「選題」。選完這個題目要怎麼傳遞給團隊、傳遞得多細緻，歸根結底還是取決於團隊如何協作。如果產品設計、視覺設計、UI 設計、系統分析、技術架構等事項都有人分攤，那麼 PM 大概就不必決定整體色調要偏藍還是偏綠、也不用回答「按這個鈕後面實際上是去打什麼資料」這類問題。她更需要做的，是清晰地劃分出商業需求以及打算切入的角度（如要契合的需求、要填補的市場空缺、預計採用的商業模式等），然後以此為基礎上，在過程裡與各領域的協作者一起前進，判斷和彌補彼此的不足。
團隊若追求敏捷，大概就不會讓這麼多事情各找專人負責，畢竟冗長的溝通鏈可能弊大於利；另一方面，越是偏向市場判斷的那部分工作，就越可能與公司的整體戰略相關，這個等級的決策有時是看公司糕層，可能不見得會由直接與開發團隊溝通的 PM 做。
所以你看「要不要做某種工作」這種問題怎麼會有標準答案 XD 我想我們大概可以說「確實會有一些一定用不著你做的事，但其他事情都難說」，也因此要學的技能就也變得非常廣泛、什麼都要會一點。
我一直這麼認為：好的 PM 是泛用型兵器。也許有幾個地方特別強，但其他部分也都要能在必要時上場，演個至少能讓故事繼續的配角。
分工的前提是合作
一路看過來，也許會讓你以為我在試圖探索所謂的 R&R？不過純粹個人偏見，感受上大家在討論這個東西時想處理的是分工，或者故意誇張點講是究責，卻不見得真正把心思放在合作上。我想大家在一起做事，合作是前提，是為了要妥善地合作所以才分工，那麼與其單純說「我（這個職稱）的責任應該是某個範疇吧」，不如進一步思考：「我目前能做這個，那你目前能做哪些？剩下的我們一起分擔」，而真的力有未逮的地方，再去提出要增加角色不遲。
這樣一來，每個團隊（一個公司裡可能有很多團隊）的 PM 角色定位與功能可能不會完全相同，但也許我們因此合作得更好了。
The scope of a Product Manager’s responsibilities is a topic that is often discussed but never seems to have a standard answer. Whenever asked whether a PM should do a particular type of work, my answer tends to be, “It depends.”
Why do I say this? Let’s first look at a PM’s role in product development.
Core Tasks and Collaboration Partners
I believe a PM’s most core and relatively unique task is “choosing the battleground” (not taking meeting minutes, coordinating resources, or being an alarm clock — everyone will eventually ask AI to do these things). This includes exploring hypotheses and finding solutions to meet market demands and gain deserved benefits for the company. Communication and coordination with stakeholders are also indispensable to this success.
Choosing the battleground is a very complex task, and whether one can select a topic that will sustain one still requires a lot of luck. In choosing the battleground, the market research part “may” have the assistance of other roles, such as business analysts or marketers. When the task is determined, the detailed design and planning “may” involve the participation of product designers, UX designers, system analysts, and other personnel.
Development and coding are usually not required for PMs to do hands-on work, but “launching” in the form of App Store releases, for example, involves some information related to marketing and promotion, which “may” be supported by marketing staff. After the product is launched, collecting customer feedback and analyzing user behavior “may” have the help of colleagues from product design, customer service, BI, and other departments.
“May”
Since it’s all “may,” there won’t be in some cases. When lacking these collaborative personnel, these tasks seem to naturally fall on the shoulders of the PM; after all, you are (so-called) the Owner, the mini CEO of this product! Considering the actual cost of the same period, I was also very willing to do some chores like ordering snacks during my rookie days, as someone always has to do it.
Project management is not mentioned above. If the team is well-self-organized, then it should be shared by multiple people (I’ve been there, and it’s fantastic). But you will definitely wish that your manager supports the work style. If you encounter a manager who pays more attention to details (which… could possibly be one step away from micromanagement), they probably still want someone to go and confirm everything.
Also, before your product goes live, you have to play with it a bit… oh, since we lack QA, you might as well do it.
What do you need to know, and what should you do?
There are various versions of the skill list needed to become a qualified PM; search for “PM Competencies,” and there are many. Each article reflects the areas emphasized by the author to some extent. For example, in the PM Wheel model, I use more often now, “agile” is uniquely listed as one of the 8 areas.
All articles talking about product manager abilities more or less mention “the ability to define what to do,” which is the “choosing the battleground” mentioned earlier. How to convey the selected topic to the team and how detailed it should be ultimately depends on how the team collaborates. Suppose product design, visual design, UI design, system analysis, technical architecture, and other matters are shared by other team members. In that case, the PM probably doesn’t need to decide whether the overall tone should be more blue or green, nor answer questions like “what data is actually hit after pressing this button.” What she needs to do more is to clearly define the business requirements and the angle to cut in (such as the needs to be met, the market gaps to be filled, the business model to be adopted, etc.), and then based on this, move forward with collaborators from various fields in the process, judging and making up for each other’s shortcomings.
If the team pursues agility, they probably won’t let so many things be handled by separate people, as lengthy communication chains may do more harm than good; on the other hand, the more work that leans towards market judgment, the more likely it is to be related to the company’s overall strategy, and this level of decision-making is sometimes up to the company’s senior management. The PM who directly communicates with the development team may not necessarily make it.
So you see, how can there be a standard answer to questions like “Should a PM do a certain type of work” 😔 I think we can probably say, “There are indeed some things that you definitely don’t need to do, but other things are hard to say,” and therefore the skills to learn become very broad. You need to know a little bit about everything.
I have always believed this: a good PM is like a versatile weapon. They may be powerful in a few areas, but they also need to be able to take the stage in other parts when necessary, playing a supporting role that at least allows the show to play.
Collaboration before the Division of Labor
Looking through all this, you might think I’m trying to explore the so-called R&R? But purely personal bias; I feel that when people discuss this thing, they want to deal with the division of labor or to exaggerate a bit and accountability, but not necessarily really put their minds on collaboration. I think when we work together, collaboration is a prerequisite, and it is for the sake of proper collaboration that we divide labor. So instead of simply saying, “My ( job title) responsibility should be a certain scope,” it’s better to further consider: “I can currently do this, so what can you currently do? Let’s share the rest together”, and if we really can’t do it, then it’s not too late to propose adding roles.
In this way, each team’s PM role positioning and function (there may be many teams in a company) may not be exactly the same, but we could collaborate better because of the mindset.
