產品生命週期：產品功能之旅

這是我正在撰寫的五部分系列文章的第四篇，旨在幫助有抱負產品的人進入產品管理領域。

在我的上一篇文章中，我將產品管理的學科分解為四個部分，旨在幫助有志於產品管理的人了解他們在公司或一般情況下的職業軌跡。 在這篇文章中，我將討論產品功能的生命歷程，從構思到放棄，以幫助有志於產品管理的人從 360 度角度了解產品經理的角色所涉及的內容。

T – 30 天

有人說，需要是發明之母。 這實際上是涉及產品功能誕生的情況。 這一切都始於某種程度的不適。
公司的一些員工在完成他的一項日常任務時面臨著不適——也許用戶群已經增加，而他無法使用舊流程進行管理。 公司中的一些高管查看 Excel 表並認為公司損失了太多錢，例如，大量產品取消。 或者，競爭對手推出的產品功能可能導致客戶離開該公司的產品。 查看營銷轉化漏斗的人注意到某個階段的流失率很高，並認為優化這可能有助於他實現季度目標。 或者可能是 100 種不同的原因，從針對常見問題的大量客戶投訴到上週接受調查的大多數用戶要求的新功能。 關鍵是——這一切都始於某種程度的不適。

現在，這種不適已引起產品經理的注意； 或者產品經理可能是第一個注意到它的人。 這是啟動可能導致新功能誕生的一系列事件的點。

T – 25 天

現在是產品經理仔細考慮問題陳述的時候了。 他去與報告不適的客戶或內部利益相關者交談，然後與實際經歷的人交談； 所有這些都是為了一個目標——確保他已經確定了“根本”問題陳述。 如果這個階段被輕視，或者產品經理沒有花足夠的時間在這上面，那麼產品的特性是脆弱的，扭曲的，很快就會達到目的。
一旦產品經理確定了核心問題陳述，他就會決定是否值得解決。 不適真的很大，還是有點誇張或更糟，只是編造的？ 解決它實際上會為客戶和/或公司增加顯著價值嗎？ 解決它不會對客戶和/或公司造成重大損失嗎？ 有沒有辦法通過對流程進行細微調整或通過任何不需要更改產品的活動來解決這個問題——比如更換供應商、與現有供應商協商更好的價格、獲得第三方軟件來解決問題、招聘額外的員工、內容、圖形、號召性用語按鈕等的變化？

基本上，如果有一種方法可以讓我們從不涉及產品更改的方法中獲得類似的增值，那麼我們將尋求改變產品中的任何內容——無論這意味著添加還是刪除。 一旦產品經理確信解決問題陳述將提供顯著的價值，並且產品級別的更改將比非產品級別的更改帶來更多的投資回報率（考慮時間、金錢和努力與/秒的價值），新的種子產品功能被種植。

T – 15 天

如果產品經理有一些先前的經驗，他可能會根據該經驗提出解決方案。 但是，這可能不是所有情況下的最佳解決方案。
如果問題陳述需要高度技術性的解決方案，產品經理會與開發人員和工程經理討論相同的問題，並聽取他們的建議，以最佳方式解決問題。 如果解決方案需要更改設計級別，則可能會諮詢 UX 負責人。 可能是產品經理和用戶體驗人員組織了一個設計衝刺並選擇了該功能的實際用戶很好接受的解決方案。 有時問題完全與業務相關，因此需要高級管理層的支持。
因此，可以有多種方法可以最終確定解決方案。 但是一旦成功，產品經理就負責將理論解決方案轉化為有效的產品功能。

T = 0（又名產品特性的誕生）

確定特定解決方案後，產品經理與相關團隊合作，制定解決方案的基本輪廓。 它可能包括也可能不包括解決方案的原型。 有時它只是一個基本的 Excel 表，其中包含“if-then”條件，用於何時向用戶顯示特定 CTA 等。
產品經理在相關的 PRD（產品需求文檔）中將解決方案轉化為文字。 如果功能很小，它可能只是現有 PRD 中的一個段落，用於更大的功能。 有時該功能非常龐大，以至於需要完整的 PRD 才能正確詳細說明它。 PRD 由相關團隊運行，產品經理確保就該功能達成廣泛共識。

T + 15 天

小功能可能需要不到一天的時間才能凍結。 有時，大型功能需要 30 多天才能獲得所有人的批准。
讓我們平均用 15 天的時間來說明，這是向開發者介紹新生功能的時間。 適當的設計和 PRD 交接發生在項目工作的開發人員被告知 5W（什麼、為什麼、何時、何地、誰）和測試用例（該功能在發布後應該如何表現或不表現）的情況下.
與工程經理一起為該功能確定適當的發佈時間表，其中包括開發結束時間、測試開始時間、報告的錯誤何時修復以及最終發布日期的截止日期。 然後將整個時間線劃分為可衡量的衝刺（通常為 15 天）。 一旦開發人員滿意，開發就開始了。

T + 30 天

Sprint 1 結束。 推出了產品功能的一部分。 它可能還不是面向客戶的，但當今大多數團隊都遵循敏捷方法進行軟件開發——這意味著我們以增量和迭代的方式構建。 因此，我們不是在 6 個月內構建一個大功能並立即發布所有功能，而是將整個功能分解為可以獨立運行的獨立部分（一堆用戶故事），並迅速準備好進行審查和迭代。
產品經理通過每日 Scrum 會議和與從事項目工作的相關工程經理進行討論，確保發佈時間表按部就班。 如果有延遲，時間線會相應調整，或刪除小部分功能以確保按時發布。 在每個 sprint 之後，所取得的進展都會在會議上提交給產品經理和相關利益相關者，並在批准後發布。
一年的 UpGrad 產品管理計劃

T + x 天

經過 'n' 次沖刺後，開發完成，整個功能都出來了。 客戶沒有必要僅在完全發布後才能使用該功能。 他們可能會在 sprint 1 本身結束時使用它。 每個後續的 sprint 週期發布只會使該功能更加強大，並使其更接近預期。
發布一個功能本身就是一門藝術，涉及很多我們將跳過的步驟，只是假設在經過大量的鼓掌和搥胸之後，它向全世界宣布了一個功能已經發布。 這可能與 CEO 本人談論新發布的完整新聞稿一樣複雜，或者可能只是將郵件發送到將使用該功能的特定部門並可能在第一名。 既然該功能已經發布，讓我們給這個功能起一個名字——Mr. Feature。

T + y 天

即使在最終發布之後，有時也會出現問題。 曾經光鮮亮麗、價值連城的Feature先生可能已經不一樣了，可能有多種原因。 產品週期中的這個階段是關於支持產品的。 一個美好的一天，發布了另一個版本，導致 Mr. Feature 以意想不到的方式執行（又名成為錯誤），或者可能刪除了另一個依賴於 Mr. Feature 的功能，這導致了錯誤的行為。 也可能是在製作該功能時，我們低估了將使用它的用戶數量，或者沒有計劃所有用例，現在該功能無法擴展到這麼多用戶或用例。

這要么是測試團隊在他們的定期審查中報告的，要么是某個團隊成員在自己使用該功能時發現的。 對於面向客戶的功能，這些投訴可能來自產品的實際客戶，並通過客戶體驗團隊傳達給產品經理。

產品經理試圖了解錯誤的根本原因，並根據優先級安排下一個發布週期的修復——如果它是高優先級甚至後續的 sprint，它可以添加到當前的 sprint 中。 在修復並發布 bug 後，Mr. Feature 將迎來新的一天，儘管是經過改進的形式 - Mr. Feature 2.0 - 感謝產品經理和工程團隊。 贊！

T + z 天

據說所有美好的事物都必須結束。 可悲的是，Mr. Feature 也是如此，無論它的版本是什麼——也許 Mr. Feature 9.263.75！ 這意味著Feature先生已經過著漫長而幸福的生活，但現在路的盡頭就在這裡。
這可能是由於各種原因。 出現了一個新功能，這使得對 Mr. Feature 的需求完全多餘。 這也可能是一些極端的事情——就像公司認為儘管該功能為其用戶增加了價值，但對他們來說不再具有經濟意義。

不管是什麼原因，都會通知產品經理（或者他是開始討論的人），不再需要 Feature 先生的服務。 現在，儘管令人心碎，但產品經理有責任讓 Feature 先生休息。 雖然在此之前，他需要確保一些事情，比如通知正在使用 Mr. Feature 的用戶從特定日期起將無法使用，但新功能在刪除 Mr.Feature 之前運行良好，沒有其他當 Feature 先生離開時，流量會受到影響，依此類推。

因此，是時候對 Feature 先生說 RIP。 在您的產品管理職業生涯中，您將不得不多次這樣做。 但請記住，一個功能的結束是另一個功能的開始，並且循環繼續。 這就是產品經營的生活！

從世界頂級大學在線學習產品管理課程。 獲得碩士、Executive PGP 或高級證書課程以加快您的職業生涯。

為您推薦的特色課程： 杜克 CE 的設計思維認證課程