產品路線圖不是純粹的功能列表
2023-03-31 16:34:28 2
產品路線圖不是純粹的功能列表。您應該放棄對函數的過度關注，但是要關心我們最終想要什麼以及需要解決什麼。這樣，你就可以擺脫功能路線圖的束縛，轉向更科學的產品開發模式。
其中，在WorldRemit工作的前3年，我為公司製作了10多種不同類型的產品路線圖。
改變設計理念的原因是，我希望通過嘗試至少具有一些優勢，找到最有效的產品路線圖：更有針對性、更有效的與股東的溝通，以及領導團隊高效地協作。
在我看來，大多數產品路線圖現在都有一個共同的大問題：產品路線圖被製成一個純粹的功能列表，唯一的區別是這些功能被放在一個時間線上（並且不是很清楚）。
事實上，功能列表存在很多問題。最直接的事情是公司，包括你的客戶，會認為這樣的功能清單是你的承諾，你會毫不猶豫地兌現承諾，這給開發團隊帶來了巨大的壓力，並且必須是原創的和本地的，才能遵循這個清單。南牆，你不回頭。
回首過去，您會發現這些功能根本解決不了問題，即使它們解決了，它們也是很小很微不足道的問題。這個團隊的任務是日復一日地完成列表上的任務，即使產品開發的環境（包括G公司的戰略、用戶需求、行業競爭格局等都發生了變化。
作為一名產品經理，列出一系列的職能會讓你處於尷尬的境地。大公司的頂層和底層公司治理文化清楚地定義了主管和股東在產品開發中的絕對話語權。他們向產品團隊提供功能開發指導，並且團隊只能遵循這些指導。
類似地，如果你加入一家商業公司，公司的創始人通常會決定如何完成產品，只要你給他一個空白的清單，它會立即填滿你。
此時，作為產品經理，您幾乎沒有自主權，充其量只是一個指令接收器，您只需要嘗試並嘗試呈現老闆想要的功能。
在功能路線圖的框架中，即使你是一個好的產品經理，也只能確保你做得很好，並且你不能控制產品的整體有效性，這就像贏得一場又一場局部戰爭，最終輸掉整個戰爭。
設想一下：到年底，你完成了產品的開發，並向管理團隊匯報，你告訴他們計劃中的所有功能都已經完成了。不管你做的是什麼不可思議的任務，他們仍然會對你大吼大叫，說你打中了他們的想法。一點效果都沒有。
如果您正在執行面向功能的路線圖，那麼很可能會發生這種情況，可能是因為您被迫開發的功能沒有達到預期的效果，但是您仍然必須最初執行它。
從現在開始，您應該放棄對函數的過度關注，但是要關心我們最終會遇到什麼以及需要解決的具體問題。
試著問問自己，如果我們的產品開發成功，將會給世界帶來什麼樣的變化我們的用戶會有什麼樣的體驗他們能用我們的產品做什麼
在特定的時間段內，每個團隊都應該為共同的、明確的目標或結果而努力，而不是草率行事。
任何好的目標都應該被測量和測量。同樣，必須驗證您設置的結果。最直觀的反饋是，你的產品能得到用戶和行業的認可嗎
如果結果是，用戶可以看到更多的廣告，這對於用戶來說是毫無價值的，並且由於這個結果，在商業上不太可能成功。
因此，產品經理不再是管理的管理者。如何進行產品開發，開發出什麼樣的功能，達到什麼樣的效果，已經成為整個團隊的問題。
這種方法的最大優點是團隊在團隊中具有更大的自主性，並且每個成員都能夠發揮其專業專長和創造性。L是實現的，我們不需要管理任何功能。
當你對自己想要達到的結果有更清晰的理解時，你會發現自己比以前更加開放，更有可能解決問題。
EdwardDebono博士（EdwarddeBono）在他的書《橫向思維》中引用了一個非常經典的例子：一個大公司的經理遇到了一個問題，公司搬到了一座新的辦公大樓，結果發現，該大樓的設計師沒有得到考慮，也沒有配備足夠的電梯。員工經常抱怨電梯很長時間。
許多管理人員提出了加快電梯速度，或者在建築物中切割電梯軸以增加體積的方法。然而，他們最終採取了不同的方法，並採用了完全不同的方法，這也成功地解決了這個問題。
他們在電梯的入口處安裝了很多鏡子。當他們早上來上班時，他們把注意力集中在鏡子裡，忘記了等待電梯的辛勤工作。
在這種情況下，管理人員真正需要解決的問題不是電梯不夠，而是員工在等電梯時的煩惱。
這種新設計思想的另一個好處是避免開發團隊向產品添加過多的功能，尤其是用戶不需要的功能。
結果驅動的方法可以引導團隊集中精力改進現有功能，最大化這些功能的影響，而不僅僅是考慮添加新功能。
我曾經和一個朋友討論過這個問題。他的電子商務產業最重要的指標之一就是轉化率。他們有年終統計數據。結果表明，推廣的重點不在於新功能的添加，而在於現有的工作，通過優化圖像處理技術等技術改進，大大提高了網絡加載的速度。
但是，像其他任何方法一樣，再次嘗試是不合適的。在本文的其餘部分中，我想重點介紹什麼是可能的以及如何避免結果驅動的方法。
首先，最重要的是，如果你的公司沒有明確的公司戰略，那麼結果驅動的產品路線圖將不可避免地失敗。
在WorldRemit，我們首先定義公司的年度目標，利用這個目標來明確團隊的任務，然後從任務開始細分季度目標和要達到的關鍵結果。
我見過太多的球隊跳到最後一步，沒有確定一個共同的目標，走到最後。
出現這個問題的原因是，您的公司正在經歷從原始的傳統企業文化到結果驅動的產品開發框架的轉變，不再關注特定功能的開發。
如何驗證這個想法的可行性，本課題本身可以在另一篇文章中討論。這裡，我使用一個圖片來說明如何在開發過程中使用用戶的反饋來驗證它。
這通常是過渡過程中最大的絆腳石。這裡有幾種不同的方法來解決這個問題：勇敢地向別人解釋你的想法。看起來我們很少花時間和其他人解釋他們的方法，這似乎是整個行業的常見病。
大多數人認為，如果一家公司比我們公司好，他們仍然在規則中。為什麼我們必須調整然而，只要你能解釋清楚，科學方法還是很容易被別人接受的。有人建議你用一些隱喻來使你的表達更加生動。
例如，你可以說，如果我是遠徵隊的隊長，我命令建造一座橋梁，而隊員們可能會花很多時間尋找橋梁的材料，而且橋梁可能不夠堅固，無法滿足整個隊伍的安全。
但如果我告訴他們我希望球隊安全地過河，那麼球員們可能會想出各種各樣的方法：做木筏，尋找河灘等等，而且每個人都很清楚什麼時候可以過河——也就是說，每個人都可以過河。
如果你這樣問領導：我們明年要做產品路線圖。你認為有什麼功能需要補充嗎您必然會得到答案：我們必須在著陸頁面上添加一個藍色窗口小部件，並放一個視頻告訴用戶我們能夠提供什麼樣的服務。
事實上，我們建議您就現有的問題提問，例如：我們明年的目標是提高登陸頁面的轉換率。你認為什麼原因導致用戶數量下降
嗯，你可能會得到一個更具建設性的回應，比如：我們認為轉換率很低，可能是因為他們不知道我們能夠提供什麼服務。
有時你會發現添加新功能只是你的一廂情願，而功能越少越好。微軟已經通過一項實驗發現，幾乎13對產品有負面影響，而13根對產品沒有影響。
如果領導不同意你的計劃，試著找到一個低成本的測試，並在合適的機會向他們建議先測試效果。
如果您與以前相同，那麼很容易確保每個人都根據不同的功能進行分工，但是當您將其更改為結果驅動的方法時，很可能會遇到這個問題。
例如，在共同目標的指導下，不同的團隊有不同的開發任務，當這些團隊之間存在矛盾時，他們應該如何區分優先級
例如，團隊的任務是減少產品內的誘導性宣傳，而另一組的任務是提高用戶的轉化率。顯然，兩者之間存在著一定的衝突。此時，有必要組織您的產品開發團隊一起進行諮詢，並且我們必須對情況有一個清晰的認識。
我已經介紹了結果驅動方法的好處，以及如何處理一些常見問題，但是您必須承認，有時您需要產品路線圖，特別是當存在外部團隊時，因為他們需要知道何時將介紹您可以做什麼。
退一步講，即使一個符號化的產品路線圖也可以在一定程度上消除他人的關注和疑慮。但是您需要調整您的心態，而不是將產品路線圖看作一個義務列表，並且實現結果比啟動功能更重要。
事實上，您必須有一個清晰的路線和地點來構建產品路線圖，但是對於真正的企業來說，無論從產品設計還是工程的角度來看，都難以做到這一點。
每一個產品的開發都像是對新世界的探索。你知道你想去哪裡，那是你想達到的，但是沒有明確的路線。結果，你只能踏上旅程，每走一步，準確定位你自己，並獲得反饋，然後你就可以沿著正確的道路到達你所期望的。
事實上，直到旅行結束，你才能回來繪製完整的產品路線圖。這個想法是改變世界，還不如暫時忘記功能，注意結果。
