作為產(chǎn)品經(jīng)理，我們都想呆在一個成功的團隊里面工作，那一個強大的產(chǎn)品團隊中最重要的特征是什么？我終于強迫自己想出了十點我認為最重要的特征。

  正好一年前我被邀請至布達佩斯，在Craft Conference中做了一個演講，我談論了十點關于產(chǎn)品團隊會失敗的原因。

  我主要講述了為什么許多團隊如此效率低下，盡管他們認為效率很重要。大部分的產(chǎn)品管理在任何有意義時期都很難“敏捷”起來，因為總體上來說，管理仍然是“瀑布“的方式。會議組織者今年又把我請回來了，去繼續(xù)討論這個話題，去討論更多我所知道的——最好的團隊是如何工作的。

  上個星期我上傳了這個演講，所以這篇文章是一個敘述版本。

  在第一次演講之后，有相當多的人聯(lián)系到我，問了更多關于選擇的東西。除了推薦他們?nèi)プx我的書，或者參加一個為期2天的研討班之外，我想不到一個更滿意的回答。所以，它激發(fā)我去更深入的思考，一個強大的產(chǎn)品團隊中最重要的特征是什么，我終于強迫自己想出了十點我認為最重要的特征。

  持續(xù)探索與交付

  正如我講述了瀑布模型環(huán)境下的十大弊端，我也講了在持續(xù)探索與交付模型（同樣以“雙軌敏捷”著稱，或者叫“探索短跑交付沖刺”）環(huán)境下成功團隊的十大屬性。

  成功的關鍵

  1. 授權產(chǎn)品團隊

  所有最重要的特征是強大產(chǎn)品團隊的絕對基礎概念。但那到底是什么意思呢？

  首先，重要的是團隊的持久性；這意味著團隊成員不能像棋子一樣被移來移去。如果他們想要實際創(chuàng)新，他們需要時間來了解彼此，了解他們的技術、客戶以及行業(yè)環(huán)境。

  其次，團隊成員之間的情感共鳴是關鍵。這意味著理解并足夠尊重彼此，每個團隊成員在貢獻、提建議的時候都感到很舒服，挑戰(zhàn)自我，促進彼此做得更好。

  第三，這意味著團隊擁有必要的多樣性技能，這些技能常常是指產(chǎn)品管理、用戶體驗設計以及開發(fā)，許多情況下我們還得用上數(shù)據(jù)分析和用戶研究。

  最后，盡管對于許多公司這是一個敏感的話題，也很難去爭論co-located(同處一室)團隊的優(yōu)勢。co-location指的是產(chǎn)品經(jīng)理、產(chǎn)品設計師、工程師（或者至少是技術領導）全部彼此坐在一起。我們不可能所有的團隊都實現(xiàn)co-location，但是我們在嘗試。同時需要清楚的是，團隊跨地點并沒有什么問題，只有當單個團隊被分裂，導致了速度尤其是創(chuàng)新上的消極影響時才是問題。

  2. 產(chǎn)品愿景以及戰(zhàn)略

  為了使產(chǎn)品團隊實際被授權并且行為有一定意義的自主性，團隊必須對更廣泛的行業(yè)背景有一個深入的理解。這從一個清楚并有吸引力的產(chǎn)品愿景開始，我們通常把這條實現(xiàn)產(chǎn)品愿景的途徑稱之為產(chǎn)品戰(zhàn)略。

  產(chǎn)品愿景描述的是我們正努力打造的世界，通常介于2-5年（對于硬件工作則更久）。

  產(chǎn)品愿景必須是鼓舞人心的，如果做得好，它將是我們最有效的招聘工具之一，激發(fā)人們每天來上班。強大的技術人員會被一個鼓舞人心的愿景所吸引，他們想做一些有意義的事情。

  產(chǎn)品戰(zhàn)略是指在實現(xiàn)愿景的道路上我們計劃輸出的產(chǎn)品次序。嘗試用一個產(chǎn)品就取悅所有人，這樣的策略是十分愚蠢的。相反，對于市場、地理以及人群，我們應該有一個優(yōu)先列表，我們專注于實現(xiàn)適合每個市場的產(chǎn)品／市場。

  你擁有的團隊越多，越是需要一個統(tǒng)一的愿景和戰(zhàn)略，以便每個團隊都能做出好的選擇。

  最重要的是，產(chǎn)品愿景應該是鼓舞人心的，而產(chǎn)品戰(zhàn)略應該是有非常有目的性的。

  3. 專注于業(yè)務成果

  為了能夠做出好的決定，一個被授權的、有自主性的團隊所需要的業(yè)務環(huán)境的第二部分，是設置業(yè)務目標的優(yōu)先順序。OKR系統(tǒng)（Objectives and Key Results）正好有助于促進這些。

  OKR反映了團隊正在解決的詳細業(yè)務問題列表。這些不是功能，功能只是這些問題的潛在解決方法，啟動一個功能不是一個團隊的成功，解決真正的商業(yè)問題才是。

  這些績效管理技術背后的兩個原則是：首先，如果你給團隊的是你需要他們解決的問題，而不是給他們解決方法的話，團隊將會表現(xiàn)得更好；其次，用結果衡量團隊，而不是產(chǎn)量。在路線圖中輸出功能是產(chǎn)量，解決業(yè)務問題則是結果。

  4. 合格的產(chǎn)品經(jīng)理

  可悲的是，許多工程師從未有一個機會和一個有能力的產(chǎn)品經(jīng)理一起工作。那些有過的工程師們堅信他們團隊中有這樣的產(chǎn)品經(jīng)理。糟糕的是，許多的工程師甚至不知道產(chǎn)品經(jīng)理應該給團隊貢獻什么。

  這樣考慮吧。為了產(chǎn)品團隊解決復雜的業(yè)務問題，僅僅是技術上的解決方案是不夠的，客戶喜歡也同樣是不夠的，最困難的是，解決方案必須真正為你的業(yè)務工作。

  想一想這意味什么。想象你正在為Uber、Airbnb工作，你必須面對復雜的法律、工會以及貿(mào)易組織?；蛘遝Bay，不得不面對一些重大的限制條件，來被歸類為市場而不是一個電子商務網(wǎng)站。或者Tesla不得不面對自動導航儀的責任問題。每個公司都有一個關于這些限制條件類型的列表。

  有法律限制，金融限制，銷售和定價限制，品牌和市場限制，隱私限制，安全限制，合作契約條件等等。

  不幸的是，很多情況下唯一能夠完成這項工作的人是CEO，這樣的話你就可以想象，為什么他或她真正授權給團隊做決定會感覺到不舒服。

  那團隊應該如何做呢？有三種選擇：一是CEO或者其它的執(zhí)行人員決定一切；二是無能的產(chǎn)品經(jīng)理安排一個大的會議，邀請高管們參加，讓他們討論出結果——這就是所謂的由委員會設計——他們一貫產(chǎn)生糟糕的結果；三是產(chǎn)品經(jīng)理做好自己份內(nèi)的工作，學習這些限制條款，把它們帶入團隊，以便產(chǎn)品團隊能夠明白解決問題的最好方案。

  結合對技術的深入理解、對用戶和客戶的深刻認識，你就能夠明白為什么這是一個艱難的工作。這也同樣是一個強大產(chǎn)品團隊的關鍵，尤其是如果團隊想要任何意義的自治的話。

  5. 協(xié)同驅(qū)動（collaboration-driven）解決方法

  我在這里不是將”collaboration”作為一個流行語在講。我這樣說的意思不是指一個產(chǎn)品經(jīng)理整合需求（“requirements”），一個設計師設計漂亮的東西，工程師在那里寫代碼，相反的是指三種技能——產(chǎn)品、設計和開發(fā)——真正協(xié)同起來解決問題。這是因為有了好的解決方法，技術驅(qū)動功能和功能驅(qū)動技術是一樣的。技術能動設計選擇和設計驅(qū)動技術選擇是一樣的。設計指導驅(qū)動功能和它反過來也是一樣的。

  關鍵在于技術、用戶體驗設計以及功能全都十分錯綜復雜，只有在這三者之間反復交換意見才能得出一個好的解決方法。

  協(xié)同驅(qū)動（collaboration-driven）解決方法是co-located團隊能夠持續(xù)勝出分布式團隊的唯一最大理由。

  6. 產(chǎn)品發(fā)現(xiàn)：快速學習

  許多偉大的產(chǎn)品歸結于團隊快速試驗大量想法的能力。我們想要快速的將好想法從糟糕的想法中分離出來。產(chǎn)品發(fā)現(xiàn)是一套廣泛的方法，旨在幫助我們快速學習哪些想法能飛，哪些想法不那么好。一些想法是大的，一些想法是小的，一些是冒險的，一些是昂貴的。有時候我們需要論證，有時候我們只是需要證據(jù)。

  很多人用不同的方式描述這個產(chǎn)品發(fā)現(xiàn)，一些人喜歡將其描述成“成功之前先假裝成功（fake it before you make it）”，一些人則喜歡強調(diào)“做事從小事做起（build things that don’t scale）”。關鍵在于我們需要快速學習、減少浪費。

  用開發(fā)團隊來創(chuàng)建并發(fā)行一個真正的產(chǎn)品來試驗一個想法，是一種最慢、最昂貴的學習方法。

  7. 關注關鍵風險

  關于產(chǎn)品發(fā)現(xiàn)，這里有兩個重要的點需要強調(diào)一下：

  首先我們需要關注四大關鍵風險：價值風險——會有人買或者選擇使用它嗎？可用性風險——他們能夠明白如何使用嗎？可行性風險——我們的工程師能用已有的科技、時間和技術實現(xiàn)它嗎？以及項目干系人（stakeholder）風險——公司不同部門的人同意這個解決方案嗎？

  在產(chǎn)品發(fā)現(xiàn)期間，我們將為這四個問題找到好的答案。如果找到了，我們就有了我們讓研發(fā)團隊花費時間創(chuàng)建并提供一個高質(zhì)量產(chǎn)品并衡量解決方法的證據(jù)以及自信。

  8. MVP的角色

  MVP的概念是產(chǎn)品中最重要的概念之一，同時也是最受虐最容易誤解的概念。

  概括總是有風險的，但是我將在這兒冒著風險，提出“MVP不應該是一個產(chǎn)品”。在每一個我遇到的案子里，當團隊花費時間和錢去建立一個真實的QA’d產(chǎn)品作為他們的MVP時，我總是能在事后為他們展示如何用更少的成本和浪費來完成同樣的學習。

  所以，MVP是一個實驗，一個測試。它是常用的原型樣式之一，通常是一個用戶原型，有時是一個實時數(shù)據(jù)原型，有時是一個可用性原型。有時它們是會混合在一起。在每個案例中，它只是真實建立一個真正產(chǎn)品的一部分。

  9. 產(chǎn)品交付：釋放信心

  我站在這里不是告訴開發(fā)者如何去建立并發(fā)布軟件。正好相反，在上一個問題（團隊用開發(fā)部門來創(chuàng)建這些MVP產(chǎn)品）所帶來的問題之一，是開發(fā)團隊經(jīng)常被迫發(fā)布一些他們知道不是他們真正應該發(fā)布的軟件。這不是他們站在后面感到舒服的產(chǎn)品。也許是主要的可靠性問題，或者比例問題，或者性能問題。但產(chǎn)品經(jīng)理總是說：“這只是一個MVP，所以放松點！”

  我在這里建議，當客戶實際依賴于這款軟件來經(jīng)營自己的業(yè)務時，你不應該妥協(xié)。我們有很多好的產(chǎn)品發(fā)現(xiàn)技術測試MVP’s，這些方式能保護我們的客戶，我們的收入，我們的聲譽和我們自己的員工。

  因此，使用您的最佳實踐，并且只有當您對該版本具有必要的信心時，才能將真實產(chǎn)品發(fā)布到生產(chǎn)環(huán)境。

  10. 以客戶為中心

  我想說的最后一點有點不同。幾乎我遇見的每家公司都告訴我他們有多愛客戶，在他們的公司價值以及使命陳述中也能找到這點，但我要告訴你的是，說來容易做來難。

  當我和團隊交流的時候，我會說得特別快：如果出現(xiàn)了一個客戶產(chǎn)品問題，他們?nèi)绾位貞?？緊急程度是什么樣的？團隊有直接與客戶聯(lián)系以理解他們是否需要嗎？團隊成員知道客戶的名字嗎？他們與客戶之間是什么樣的關系類型？他們把客戶當成一種大的痛苦，還是他們認為客戶更像同事？

  為客戶灌輸這種真正的同理心和承諾的最好方法是將團隊，包括開發(fā)人員，直接連接到客戶。

  我希望這些能讓你更好地了解什么使偉大的產(chǎn)品團隊偉大。

來源：人人都是產(chǎn)品經(jīng)理