用於解釋產品管理概念的最佳 5 個圖表
已發表: 2020-02-27產品經理有很多責任和責任。 產品經理不僅需要通過創建路線圖來製定戰略,還需要向團隊闡明新產品的發布週期以及介於兩者之間的所有內容。
他們還需要具備了解如何確定優先任務並相應地管理團隊的專業知識。 不僅如此,移動產品經理還有責任分析添加到產品(移動應用程序)的功能以及它們是否與客戶的目標同步。
總而言之,與產品相關的每個流程、活動和決策都由移動產品經理同步和調整。 幫助這些產品經理實現其 KRA 的是一套特定的技能。
現在,顯然他們將被要求向他們的團隊成員解釋某些產品管理理念,以便他們都在同一個頁面上。 但是,令人疑惑的是——他們如何解釋所有的產品管理概念和關鍵思想?
好吧,我認為一些對產品經理有用的圖表可以解決問題。 如果您有興趣了解這些圖表是什麼以及移動產品經理如何以及何時使用它們,請堅持到底。
圖 1 – 通信瓶頸
據了解,作為經理,您需要了解團隊中正在發生的事情以及團隊成員如何管理他們的任務。 但是,任何人都參與到每一次溝通和決策中都是可笑的——一個人不可能一個人處理所有的事情,對吧? 這不就是代表團被發明的原因嗎?
現在,您很自然希望參與所有重要的團隊間/團隊內對話,但您需要反思一件事——有必要嗎? 是不是應該把其他責任放在一邊?
答案是——分析團隊是否有能力進行不依賴於你的溝通。 如果是這樣,您需要做出一些有意識的決定,以確保流利的溝通等重要事情不僅僅取決於您。 下面給出了一個可以有效解釋該案例的圖表。
比方說,Web 工程師需要與產品分析師討論一些事情,然後 PA 說他們需要在這方面與 iOS 開發人員討論一些事情。 現在,Web 工程師最好直接聯繫 PA 和 iOS 開發人員,而不是依賴 PM(如左圖所示)。
左邊的圖表顯示了團隊對產品經理與其他團隊其他成員溝通的依賴——這會對工作流程產生不利影響並減慢它的速度。 右邊的圖表顯示了一個不依賴的高效溝通流程,立即消除了不必要的聯繫點。
圖 2:瀑布與敏捷
儘管互聯網上有很多資源參與了敏捷與瀑布方法的辯論,但它對於產品管理來說似乎仍然是一個模糊的概念。 因此,讓我們清除模棱兩可的迷霧。
眾所周知,移動應用程序開發的成本是根據開發該產品所需的時間來計算的。
現在,如果那個移動應用程序開發公司的產品經理選擇使用瀑布式方法(即產品的大版本),這將意味著產品將一次性推出。
現在,當一個產品發佈時,它有望成為一炮而紅——這在這種情況下並不容易,因為產品是一次性推出的,而且肯定會引發一些問題。 他們從這個版本中獲得的價值將不等於開發人員所做的投資(時間)。 這是因為他們需要從一開始就解決問題。
相反,支持小版本和迭代的敏捷方法將顯示即時的價值結果,因為您同時識別和修復錯誤。 上圖清楚地顯示了選擇這些產品管理方法的最終結果的差異。
圖 3:交貨規模的表示
當談到按時交付產品時,它是整個開發過程中非常關鍵的部分。 從字面上看,它可以成就或破壞任何移動應用程序的未來。 如果上市時間過長,其他一些應用程序可能會佔領市場,這會使有問題的移動應用程序徒勞無功。
以下是開發應用程序時採取的舉措規模的表示 -
左圖顯示了僅處理大型項目(同時處理大量工作)的交付規模的吞吐量。 絕對清楚的是,只在一個產品的大項目上工作會在未來的某個時間點造成障礙,因為這些項目需要更多的時間、注意力、資源等。如果出現任何問題,影響將是對整個過程造成破壞,不可避免地會增加產品上市時間。
{另請閱讀我們關於“項目經理與產品經理:差異、角色和挑戰”的文章}
右圖是一個經典的“待辦事項”。 採用敏捷方法的優勢也波及到產品管理流程的這一階段。 這種方法提倡將執行小任務與大量工作(藍色)相結合,我們在 Appinventiv 也遵循這一點。
如圖所示,與左邊的不同,這裡的小塊工作(粉紅色)可以輕鬆通過漏斗(可以輕鬆完成)。 如果這些證明是成功的,產品經理可以繼續這個想法(黃色圓圈)並完全投資。 如果情況並非如此,那麼他們可以再次迭代並進行相應的投資。
{查看這篇關於“產品經理必須準備的 10 個最重要的文件”的詳細文章}
圖 4:領導參與程度
下圖包含兩個模型,用於闡述這個產品管理概念。 左邊的一個顯示計劃規模、一次完成的任務數量以及其中的風險因素,另一個涉及與這些任務和計劃相對應的產品經理(領導)的參與程度。
左邊是團隊要執行的任務/計劃的金字塔。 金字塔的底部意味著同時執行許多任務,右側的圖表顯示了這些低風險甚至無風險的瑣碎任務的參與程度。
當我們移動到金字塔的頂部時,任務的數量會減少,而與這些任務相關的風險也會增加,這是必須諮詢產品經理的地方,而在形成過程中,他/她可以被告知。 該圖不僅可以幫助移動產品經理,還可以幫助團隊成員了解何時依賴領導。
圖 5:分析分割值
有一些組織習慣於遵循的做法。 其中之一是優化平均值而不是細分的習慣。 這意味著,他們傾向於關注平均水平,而不是需要改進的特定部分。
在目標和假設相當廣泛的情況下,產品經理和開發團隊很難通過產品產生影響。 這是因為你在這裡試圖同時滿足各種目標,這根本不可能。
圖表(如下所示)是一種分析每個部分以識別哪些部分正在影響其他部分的表現的方法。 這一切都是為了解決普遍存在的問題。
上圖由三個假設的實驗 1、2 和 3 組成,分別是 A、B、C 和 D 段。在三個實驗中,在第一種情況下,A 段有上升,隨後下降第二種情況,第三種沒有變化。
單獨來看,在實驗 1 中,除了 B 部分,A 部分與其他部分錶現良好。現在,該圖突出顯示了與其他部分並列的該部分的下降。 這可以幫助產品經理找到發生這種情況的原因,從長遠來看最終會提高平均水平。
類似的情況發生在實驗 3 中,其中 A、C、D 段在顯示出顯著變化的對立段 B 中表現不佳。 同樣,一項研究將闡明發生這種情況的原因。
這些對產品經理有用的圖表可以很容易地根據自己的需求進行定制,無論產品經理從事哪個行業。就 Appinventiv 而言,我認為這些模型確實有助於我們的團隊簡化流程並保持內部之間的開放式溝通/團隊內。
經常問的問題
1. 什麼是產品管理框架?
所有的框架本質上都是產品管理生命週期中使用的工具。 它們用於各種目的,例如說明產品管理思想和概念並促進其他任務。
2、產品管理流程是怎樣的?
產品管理過程包括不同的階段。 它包括——創意管理、路線圖、添加和確定規格、優先級、交付、分析和用戶反饋。