崗位職責內容分析「產品管理的主要內容是什麼」

編者按：我們總是聽聞，要做好產品經理，真的是太難了。有時候，我們甚至還會聽說設計師或工程師吐槽產品經理的故事。實際上，做好產品管理，除了人際溝通能力之外，效率也非常重要。這篇文章，原標題是6 diagrams I use to explain Product Management concepts，作者Curtis Stanier是一名資深產品經理。Curtis在文中分享了他在產品管理過程中經常使用的用來提高工作效率的6個圖表，希望對你有用。

• 推薦閱讀：巴菲特認為，掌握這項技能可以讓你的財富增加50%

圖片來源：Pexels.com

在人際溝通中，我們可能都有一個共識：能用圖表達清楚的，盡量就不打字。老實說，我認為圖的重要性遠不止於此。圖片不僅可以增進你的共識，而且還可以為你減少書面語言所帶來的複雜和一些不明顯差別。

在這篇文章中，我希望給大家分享我在日常工作中，討論有關產品管理想法所常用的6個圖表。這些由我自己手繪而成的圖表，不僅廣受歡迎，而且更重要的是，它們能讓人快速便捷地了解有關思想。

這6個圖表分別是：

• 「產品經理瓶頸」圖
• 「大小任務流量」圖
• 經典「瀑布與敏捷」圖
• 「方案大小、風險及領導參與」圖
• 「知識柱狀」圖？
• 「分段價值」圖

如果你覺得它們對你的工作有幫助的話，那就盡情享用吧。

圖表1：「產品經理瓶頸」圖

我發現，許多產品經理最常犯的錯誤之一，就是自我感覺良好，認為自己不能漏過任一工作環節的討論。可以理解的是，有這樣的想法，的確存在工作態度積極的成分。畢竟，你是產品經理，為了做到產品開發過程中的面面俱到，你也需要盡量地全面了解各方面情況。

遺憾的是，這樣的做法，也存在許多明顯的弊端。

首先，這種做法有點不太切合實際。你很快就會發現，自己有一大堆事情做不完。這不僅會對團隊效率產生負面影響，而且還對給自己的帶來一定的壓力。相信我，我在這方面是過來人。

其次，這種做法也是在破壞團隊成員的自主工作。

優秀的產品經理，他們知道該何時介入相關工作之中，也知道何時又該「全身而退」。他們知道自己不必參加哪方面的討論。讓團隊成員自主工作的目的，也就是在於儘可能地減少他們在各方面的依賴。

在下列圖表所示的案例中，你可以試想一下左圖中的工作場景。

網頁端開發工程師向產品經理提出一個需要開發的概念，於是產品經理就去跟產品分析師溝通有關事宜。產品分析師稱，這個開發必須做到與iOS系統同步匹配。隨後，產品經理又去跟iOS系統開發工程師溝通，收集相關細節信息，再反饋至網頁端工程師那邊，跟他們解釋探討。

這樣的工作方式，不僅給產品經理造成了許多不必要的工作，同時就網頁端工程師所提出的問題，在解決速度和效率方面也出現了怠慢。

相比之下，在圖表右側的工作場景示例中，如果網頁端開發工程師能夠直接跟產品分析師溝通，從他那裡了解有關需求，然後他們再直接跟iOS系統開發工程師保持同步溝通，這樣也能完成這項工作。

你也會發現，這樣的溝通方式，相比於左圖少了許多不必要的溝通交流（見上圖紅色箭頭）。

此外，如果我們在前述圖表案例的基礎上，再增加其它幾個需要同事討論的其它內容（見上圖綠色和藍色箭頭），這樣的模擬也更符合真實工作場景中所遇到的實際情況，那你就會看到，如果產品經理需要介入每一項工作的話，那需要他去溝通處理的事情數量，會大幅度地增加，而且每一項事情的溝通進展，都必須通過產品經理來溝通完成。

如何使用「產品經理瓶頸」圖？

如果你在工作中總是在各項任務中忙得不可開交，那你就得停下來，思考團隊成員之前的溝通交流是否存在問題。

試問自己：自己是否需要參與每一項溝通交流？如果你在休假期間，團隊成員的工作進展是否仍然可以穩步向前推進，還是會全方位停止？如果是後者的話，那你能做的，就是去思考，在沒有你的情況下，到底怎樣才能促進團隊成員之間的溝通交流。

圖表2：「大小任務流量」圖

這個圖表我個人非常喜歡，它可以用來理解和分析團隊的工作量以及各項正在執行的任務大小等問題。針對產品上市問題，無論是業務合夥方，還是產品團隊的成員，他們都提到了整個過程太慢，同時也讓人非常沮喪。

造成這個問題的原因，通常都是因為只關注更重要的工作而造成的（見上圖中左側漏斗案例）。

因此，團隊一次只能完成一項任務。如果我們的工作目標非常明確，而且也無需任何調整，那可能這種方法還可以接受。然而，這種情況在實際工作中也非常罕見。等到事情從漏洞孔掉出來後，你才發現，這個事情是行不通的，那你可能就需要花更多的時間和經歷來吸取這個錯誤教訓。

敏捷方法之所以提倡小任務工作法，是因為價值可以更快地體現，同時風險也相對較低。

右圖中的漏斗就可以體現相對更大的靈活性。小任務（藍色圓點）可以快速通過漏斗並得以驗證。如果驗證成功，我們就可以投入更多精力（粉色圓點）。否則，我們就只需要在相對投入較少的情況下再次迭代。

每一次驗證，都可以讓我們進一步投入。這樣做，就可以完成一系列小任務、一些中型任務及部分大任務，既降低了一定的風險，同時又提高了投入回報。

如何使用「大小任務流量」圖？

回顧過去一個月以來自己所參與的任務。就規模和複雜程度而言，這些任務屬於大任務，還是包括了各種類型的任務？對這些任務進行標碼，比如小中大，然後思考你自己的漏斗會是怎樣的。

圖表3：經典「瀑布與敏捷」圖

實際上，網絡上有很多關於這方面的案例。所謂「瀑布」，其實就可以理解從產品概念、啟動、分析、設計、開發建造、測試、發佈的自上而下「瀑布式」的連貫工作方式，前一項任務沒完結之前，不開啟後一項任務。

相比之下，「敏捷」則可以理解為基於時間線的快速交付產品的方法，它可以根據核心框架在完成主要功能後，再通過不斷地迭代，完善細節方面的功能。

但在這裡，我想強調的是付出的這個過程。對許多產品開發團隊而言，他們都沒有讓成員明確地 意識到，團隊所耗費的時間，實際上也是一種投資。

如果所有的產品經理都有獨立的產品開發利潤表的話，他們通常都會看到，人員開支是整個團隊開支中最大的一筆費用。所以，無論如何，都要尋找一切有利機會，提高利潤（或回報）。

當團隊推出重大更新過後，你肯定希望立即就看到價值的提升。或者你甚至在更新過程中，就開始設想，這一次的更新，肯定是最完美的解決方案，不會有任何技術故障（但現實是不可能的）。

左圖為重大更新，橫軸為時間，黃色箭頭代表的是付出，藍色箭頭為價值；右圖為小型迭代更新。

左圖中，團隊成員為了一個重大更新，可能會在投入大量時間的前提下，看不到任何價值的體現。

如果提高更新頻率，每次都推出小型更新，那你就是在漸進式地完成產品開發更新工作。這種方式，你的投入很快就會看到回報，畢竟你可以更快地從錯誤中吸取教訓，也可以更快地實現價值提升。很快，產品的價值提升就會超過團隊的付出，這也是每個團隊都應該努力奮鬥的目標之一。

如何使用經典「瀑布與敏捷」圖？

通常，我會藉助這個圖表，來解釋為什麼「只多加一項任務」可能就不符合團隊的最大利益了。此外，這也是一種有效的方法，讓你提醒自己和你的團隊，思考自己的團隊角色將對業務方面產生什麼影響。

圖表4：「方案大小、風險及領導參與」圖

就這個圖表而言，主要有兩方面內容。

左圖中，是一個方案金字塔。金字塔的寬度，代表着一次性可能需要解決的方案數量。底部最寬，證明需要討論決策的方案數量最多，相應方案的風險就相對較低。而金字塔頂部最窄，證明需要討論的方案數量最少，風險自然而然地就最高。

右圖中，是一個衡量領導參與的倒金字塔。金字塔越寬，就代表期待或需要領導的參與度就越高。在這種情況下，就應該更多地諮詢領導的意見。金字塔越窄，需要領導的參與度就越低。

作為團隊成員或者產品經理，你應該儘可能多地執行小型方案。這些事項的風險通常都不高，而且還可以不斷地優化。領導不希望在這些事項上耗費時間與功夫，否則意義也不大。

然而，如果涉及到金字塔頂端的方案，通常就代表更高的風險。比如，考慮推出全新的產品。這個時候，你就需要領導的介入和支持。

如何使用「方案大小、風險及領導參與」圖？

無論是涉及領導或者團隊的情況，我發現這個圖表都非常實用。它簡單易懂，向我們解釋了為什麼領導在某些議題上必須出面，為什麼在其它方面又不必浪費他們的時間或經歷。

圖表5：「知識柱狀」圖

這個圖表來源於我的一位同事，他主要是負責對團隊運營健康進行季度檢查。通過柱狀圖的形式，來視覺化呈現部門和團隊在知識分享方面的影響，是一種非常直觀和便捷的做法。

毋庸置疑的是，我們不可能在方方面面都非常精通。然而，如果知道自己在某些知識方面存在欠缺，那你就會更關注彼此間的交流。

團隊組織（或個人）大小與意識的關係圖。縱軸從上到下反映的是意識最高與最低，橫軸中，最左是個人，隨後是越來越大的團體，分別是小分隊、大團隊、其它團隊，及其它部門。

作為團隊的一份子，你必須要充分意識到自己所做的工作。這種意識，當你置身於上一團體中會出現下降趨勢，並且在越大的團體中，相關意識可能會降低到最弱。

如何使用「知識柱狀」圖？

頻繁提醒自己和身邊的人士，你所在的團隊可能會因為沒有人在方方面面都非常精通而導致效率降低。此外，如果在團隊中出現觀點分歧或衝突時，很可能是因為缺乏相關信息才導致的，這些分歧和衝突實際上也不存在惡意。

圖表6：「分段價值」圖

縱觀大多數公司在針對產品方案和測試做出相關決策時，最常見的錯誤之一，就是對所有方案進行優化，保證平均效果，而不是擇優或分段優化。

關於「平均」可能存在的扭曲觀念，我通常都會用這個例子來舉例：普遍而言，人們平均都略少於兩條腿（由於某些人士只有一條腿，甚至沒有腿，所以普遍而言，這個平均數會略小於2）。

在產品開發過程中，如果有關假設和關注範圍過於廣泛的話，那它必然會限制團隊成員所創造的影響。這就好比，如果你想一次性安撫所有人的話，這也是不太現實的事情。

在下圖中，最右列案例三的實驗Z，可能是最常見的情況。

圖表中的三個案例，分別對應的是三種不同的假設性實驗。案例一中的實驗X，反映的是效果提升；中間案例的實驗Y，則體現的是實驗失敗，而右方案例三的實驗Z，則沒有特別的效果。

然而，如果你進一步挖掘這些實驗結果，你可能就會發現更多的機會或者限制。

在案例一中，雖然實驗成功，整體效果得到了提升，但B段實際上卻效果欠佳。在這種情況下，我會去進一步了解為什麼B段效果欠佳，甚至可能會考慮在最後推出產品時，直接移除B段。

同理，在案例三中，雖然整體效果並沒有特別明顯的變化，但B段和C段都出現了不同程度的效果提升。這兩個結果也剛好和A段和D段的欠佳相抵消。你也因此可以進一步去了解背後的有關原因。

如何使用「分段價值」圖？

在提出假設時，一定不能泛泛而談，而是要盡量具體，從而針對相關結果進一步挖掘，發現其背後的機會或缺陷。我強烈推薦資深產品經理里克·希格姆（Rik Higham）關於假設和實驗的模型，具體可搜索EXPERIMENTATIONHUB網站的假設包（Hypothesis Kit）。

此外，你也可以通過用戶體驗分析師妮基·安德森（Nikki Anderson）的方法，藉助用戶調研和人口數據來創建用戶角色，從而進一步了解你的目標對象。