構建您自己的產品發現工具箱
已發表: 2020-03-16當產品團隊開始一項新的產品發現任務時，他們的主要工作是減少不確定性。 最初的對齊和研究可能感覺是可預測的並且幾乎是線性的。 但是一旦第一個假設被證明是錯誤的，團隊就需要改正。
產品發現的複雜性讓人感到難以抗拒，但試圖通過其他公司開發的藍圖來克服它很少是可行的解決方案。 發展自己的方法更為重要。 在這篇文章中，我想分享為什麼我相信你的產品團隊的個性是有效產品發現的秘密超級力量。
個人故事：速度固定、數字繪畫產品發現和實現
我親身體驗過嚴格的（和“可預測的”）產品發現方法。 而且我在沒有創造清晰的情況下造成了我自己公平的無休止迭代。
當我在 2012 年收到 CSPO 證書時，我確信我對構建出色的數字產品瞭如指掌。 我確信我作為產品經理的突破性成功現在是不可避免的。 我所要做的就是確保我的用戶故事包含足夠的細節並遵循模板。 我能夠按需背誦敏捷宣言。
我主要通過團隊的輸出和利益相關者對解決方案的滿意程度來定義我的角色的成功。 我優先考慮提高衝刺速度和保持最後期限，而不是不斷改善用戶行為。 這就是我所關心的。
但有一次，我開始質疑新想法是如何在我們的積壓工作中找到的。 必須有更好的方法，而不是抄襲競爭對手、抓住新的設計趨勢、等待 CEO 最新的“好主意”。
在做了一段時間忙碌的產品經理之後，我被介紹了產品發現和雙軌敏捷的想法。 我立刻愛上了這兩個想法。
不幸的是，這個愛情故事的結局並不好。 我迷失在無休止的產品發現迭代中，並試圖一步一步地跟隨其他“著名”公司的流程。 當我不能完全遵循他們的方法時，我覺得我不知何故失敗了。 我們沒有探索問題空間並得出新的解決方案，而是成為我們在 Twitter 和 Medium 上挑選的模型的受害者。
示例：我們研究了運行“精益起步”的概念，因為它是由一些利益相關者提出的。 我們希望明確 MVP 的範圍並規劃前進的道路。 不幸的是，我們沒有強大的用戶洞察力。 我們不清楚這個問題是否值得解決，也缺乏真正的跨職能視角。 精益起步是啟動“敏捷項目”的“經過驗證的”過程，在內部被視為非常進步的舉措。 唉，雖然一開始是“偉大的”，但我們最終還是採用了純 HIPPO 驅動的瀑布模式（具有諷刺意味的是，這從一開始就是研討會的主要輸入）。
從那時起，我與不同行業和公司規模的不同團隊合作——既作為內部產品負責人/經理，也作為外部產品教練。 我對如何使產品發現有效的看法發生了巨大變化（而且我相信會變得更好）。
在解釋發現和交付如何齊頭並進的同時，最流行的雙軌敏捷可視化也暗示了一種與團隊每天面臨的凌亂現實分離的線性。 使發現迭代適應現有的衝刺節奏是有限的。 同樣，團隊不應該覺得有義務將每個新的發現想法轉變為開發衝刺。
我相信這種僵化的存在是因為“舒適區”重複關注衝刺中的輸出為利益相關者和團隊提供了。 只要新的想法被推到 sprint backlog 中，團隊的利用率就會保持很高，這意味著總會有更多的（感知的）價值被創造出來。
在我與團隊合作的過程中，我經常觀察團隊試圖通過更詳細的計劃和清單來解決產品發現固有的不確定性。
有一次，我與一個團隊合作，那裡的高管要求“大刀闊斧”地真正改變產品的下一個版本。 因此，該團隊獲得了探索新方向的資源。 同時，從第一天起，就可以看到具體結果的不耐煩。 控制這種不耐煩的一種嘗試是概述在接下來的幾週內將發生哪些具體的發現活動。 雖然這種方法有助於提前安排用戶訪談和跨職能構思研討會，但它很快就變成了一種“承諾”，幾乎沒有什麼可以糾正的餘地。
這讓我重新思考如何幫助團隊在產品發現“叢林”中找到自己的道路。 我開始相信，沒有一條路可以統治他們所有人。 相反，它是關於為團隊提供技能、方法和信心來定義和執行他們的個人方法。
顯然，這在很大程度上取決於公司文化。 但這是行為上的改變，也可能由個別團隊成員引發。 掌握產品發現及其結果的所有權是從功能工廠到授權產品團隊的最重要步驟之一。
將重點從交付轉向以結果為導向的發現
派遣產品團隊執行發現任務需要不同的心態（尤其是如果公司一直專注於輸出）。 對交付有用的東西並不能轉化為發現工作。 團隊必須忘掉一些習慣。
許多公司使用 Scrum 工件和儀式來闡明他們的交付工作——“需要做什麼”。 雖然理論上 2 週的 sprint 應該專注於定性的 sprint 目標，但對於大多數團隊來說，成功的最終衡量標準是通過交付“輸出”（也就是故事的數量）來定義。 在這個模型中，當團隊的速度提高時，團隊就會進步。
這種心理模型在產品發現過程中崩潰了。 為什麼？ 從鳥瞰的角度來看，產品發現的可能階段可以這樣分解：
這些階段相互建立，但不是順序/線性的。 根據上下文，它們甚至可能不是必需的。 通過一個領域工作並不能保證成功（也不能通過所有領域工作）。 從某種意義上說，您必須編寫自己的劇本。
示例：我正在為 b2b 企業工具進行 JIRA 集成。 經過一些徹底的發現工作，當我們試圖推動 MVP 的採用時，一些困難開始出現。 儘管我們已經將 JIRA 管理員確定為值得關注的演員，但我們並沒有直接與他們交談。
這真的趕上了我們。即使我們有一個我們的實際用戶喜歡的產品（並確認它解決了一個問題），JIRA 管理員有一個完全不同的觀點。 由於沒有直接與他們交談，我們完全錯過了我們需要為他們創建的行為變化。 這種認識讓我們回到繪圖板（也就是我們的影響圖），重新思考我們需要推動的結果，不僅為我們的主要用戶，而且為像 JIRA 管理員這樣的次要用戶。
發現和理解問題空間具有挑戰性。 但挑戰並不止於此。 這些見解通常很難與實際業務價值聯繫起來，這使得它們對於發現團隊外部的同行和利益相關者來說不太明顯。 團隊必須專注於問題和結果空間，而不是通過早期的功能討論獲得偽支持。 雖然您可以更詳細地計劃下一步的發現，但總體路徑通常在下一個實驗結束之前仍然不明顯。
重申上述觀點，這與以交付為中心的產品管理相去甚遠。 該團隊的任務是在開始頭腦風暴解決方案之前揭示真正重要的行為變化。 在此之前，團隊必須調整其方法。 您將需要必要的支持。
常見的反模式包括：
- 根據完成的發現活動的速度衡量團隊的成功。 這可能會幫助您確定發現方法的多樣性，但不會幫助您了解這些方法是否適合挑戰。
- 定期將每個新想法轉化為原始利益相關者想法的另一個版本。
- 沒有新見解的無休止的迭代。 在某個時候，您需要重新考慮您的方法。
- 不提交資源/時間，只做名義上的“發現工作”。
作為第一步，協作就發現任務的固定時間框達成一致。 將此時間框視為啟用約束，而不是盡可能多地檢查框。 團隊應以“盡力而為”的方式解決挑戰，並儘可能減少任務的不確定性。
團隊選擇要關注的階段和使用自己的方法至關重要。 然而，為了避免對產品發現過程的“黑匣子”認知，它應該與組織的其他成員共享這些決策。
雖然在理論上很容易就產品發現的非線性達成一致，但在現實中很難證明跳躍和循環活動的合理性。 在這種情況下，圍繞問題空間對齊的好處是一個重要的錨點。 當一個發現/洞察不能推動團隊“前進”，而是需要退後一步或簡單地重複時，團隊需要有一個基礎來支持這一點。
在大多數情況下，這應該是最後的洞察力如何增加或減少團隊對實現預期影響的信心。 如果它只是“感覺不對”，團隊將很難為非線性提供理由。
我試圖鼓勵團隊建立自己的產品發現工具箱，而不是堅持流行的框架和流程。 這與“通過”下一次發現努力無關。 相反，團隊應該努力建立這種力量並增加對未來發現工作的信心。 創建工具箱並增加組織的信任度是團隊掌握其產品發現工作的關鍵步驟。
概括
我認為是時候挑戰“正確”產品發現的想法了。 複雜的環境和不斷變化的業務挑戰需要適應性並挑戰線性、僵化的產品發現過程的想法。
重要的是，團隊要充分了解哪些方法適合他們所面臨的挑戰，並知道如何以有效的方式將它們結合起來。 由於特定的預定義產品發現流程，公司不會成功。 他們之所以成功，是因為他們鼓勵團隊找到自己的道路，並通過培訓和心理安全來支持這種發展。
準備好開始了嗎？ 這是一個可以幫助您的獎金。
對我來說很重要的是，您可以從本文中分享的故事中獲得一些有形的東西。 為了幫助您做到這一點，我為您設置了一個特殊的獎勵部分。
免費獎金包括：
- 為期 6 天的免費 Product Discovery Navigator 電子郵件課程，可幫助您在 Product Discovery 期間堅持課程
- 我在產品發現中克服確認偏差的最佳實踐
- 當我運行我的第一個 Discoveries 時，我希望我知道什麼
您可以在這裡註冊進入紅利區。