對講的產品原則：從問題做起，實現更好的解決方案

“我們要解決的問題是……”

這是對講機的常見開場白。 不僅在產品評論、路線圖會議或產品人員的設計評論中，而且在整個公司中。

這是探索我們產品原理的系列文章中的第八篇。 在這裡，斯蒂芬討論了我們的工程原則“從問題開始”。

在我們週五下午的儀式“展示和講述”中，來自公司各地的人們演示了他們一直在做什麼，這就是他們打開演示文稿的方式——他們描述了問題。 當任何新加入對講機的人時，他們的入職包中都會包含他們的第一個“Intermission”——我們的問題陳述名稱。 當你開始時，你首先要關註一個問題。

我們有充分的理由沉迷於問題。

您的解決方案與您對問題的理解一樣好。

大多數公司都失敗了。 許多失敗的原因之一 - 特別是在早期階段 - 是因為他們沒有為客戶存在的實際問題提供令人信服的解決方案。

失敗的解決方案有幾種常見模式：

• 團隊一開始就沒有很好地理解問題
• 團隊未能不斷更新他們對問題的理解以及隨著時間的推移它如何映射到解決方案
• 這個問題不值得解決——它可能太小眾或不夠緊迫，無法立即採取行動

很多時候，公司會迅速從問題跳到他們愛上的單一解決方案。 他們在這個解決方案上投入了時間、金錢和精力，但最終卻意識到沒有人真正關心它。

“真正偉大的公司意識到，製造人們想要的東西比製造人們想要的東西更容易”

真正偉大的公司意識到，製造人們想要的東西比製造人們想要的東西更容易。 這就是我們在 Intercom 嘗試做的事情——我們從了解目標客戶遇到的實際問題開始。 聽起來很簡單，但如果專注於問題如此關鍵，為什麼很少有公司這樣做呢？

人們習慣於思考解決方案

我們都聽說過“不要給我帶來問題，給我帶來解決方案”這句話。 我們的大腦一直在努力解決擺在我們面前的問題。 但是，如果我們不花時間分解、探索和分析客戶的問題，我們的解決方案就有可能落空。 以下是一些問題被忽視的原因，有利於立即解決。

“挑戰在於創建系統視圖並了解系統如何一起工作（或不工作）”

1.你的產品是一個系統

您的產品、公司和客戶群越大，準確診斷模棱兩可的問題就越具有挑戰性。

有越來越多的因素在起作用，挑戰在於創建系統視圖並了解系統如何一起工作（或不工作）。 例如，如果一個產品的使用率很低，那是為什麼呢？ 是用戶體驗或教育問題、缺少功能還是其他原因？

2. 問題定義很難

人們經常以他們想要的解決方案的形式描述他們遇到的問題。 許多產品團隊停在那裡並構建該解決方案，這通常會錯過標記，因為實際問題被埋得更深了幾層。 優秀的產品團隊不斷前進，不斷追問為什麼。

“問題定義意味著跳出你的頭腦，進入他們的頭腦，深入了解他們的實際需求——而不是他們描述的第一件事”

這可能在情感上具有挑戰性且耗時。 它需要一遍又一遍地與許多客戶交談，以新的角度和新的提問方式進行挖掘。 這意味著跳出你的頭腦，進入他們的頭腦，深入了解他們的實際需求——而不是他們描述的第一件事。

3. 解決方案很閃亮

更令人興奮的是：一份研究報告還是一個新的工作原型？ 我們大多數人都喜歡看一些新的很酷的東西。 我們沒有時間閱讀報告； 反思和獲得深入的知識通常被認為是乏味或不重要的。

在 Intercom，我們明白影響比魅力更重要。 當我們看到寫得很精彩的問題陳述時，我們會很興奮，我們知道這些陳述將成為接下來工作的有力指南針。

4. 可見的產出和對“進步”的偏見

有時，一個團隊可以投入數週的工作，並產生一個簡短的段落，闡明要解決的問題。 對於不重視這個過程的人來說，很難根據產出來推銷重要性。

遠離實際問題的利益相關者將傾向於“切實的進步”——他們更有可能對任何解決方案感到欣慰，無論它是否能解決問題。

那麼，如果這是問題所在，解決方案是什麼？

“從問題開始”作為我們的核心研發原則之一出現在首位和中心，表明它的重要性並確保我們在工作時牢記它。 這也是一個觸發器； 它激活了我們都可以利用的具體期望和工具。 以下是我們在 Intercom 中優先處理問題的一些方法。

我們允許專注於問題

在 Intercom，我們重視原則而不是流程，因此無論我們遵循敏捷、精益還是其他一些產品開發流程——這個原則告訴我們應該關注哪裡。

大多數公司將時間花在設計和構建解決方案上，而很少關注理解和優先考慮他們需要解決的問題。 如果每個團隊有 100 個關注單位，他們通常會這樣使用：

大多數公司將大部分時間用於設計和構建解決方案

大多數公司將花費大部分時間設計和構建解決方案，然後向他們的客戶發布測試版。 我們認為這是一種有缺陷的方法，過於傾向於基於薄弱的問題理解來構建解決方案。 相比之下，這裡是我們如何度過對講機時間的粗略指南：

在 Intercom，我們將時間更平均地分配到各個階段，花費大量時間來確定問題的優先級和細化問題

在我們開始設計任何東西之前，我們 100 個單位中的三分之一就已經用完了。 在這個階段，我們痴迷於問題優先級和問題定義，並隨著我們了解更多，不斷重新定義我們對問題的理解。 在流程開始時花費這段時間意味著我們知道我們需要構建什麼，並且可以更快地將其交付給客戶。

我們確定問題定義期望

我們所有的原則都可能在規模或工作量上有所不同，並且沒有固定的時間應該花在定義問題上。 您可以花一個小時、一天、一周或 10 週的時間端到端地完成整個過程。 為了幫助個人和團隊對給定問題進行分類並確定投資的適當努力，我們使用了幾條準則：

1. 在問題和解決方案之間來回跳動是可以的

在他們的書Bulletproof Problem Solving 中， Charles Conn 和 Robert McLean 將其稱為“問題和解決方案之間的鼠疫”。 這個想法是，在兩者之間進行切換會加深你對每一個的理解，但關鍵是不要愛上你對問題或解決方案的看法。

“當你試圖同時考慮客戶和業務需求時，可能會造成混亂”

2.從客戶的問題開始，而不是從業務開始'

當您嘗試同時考慮客戶和業務需求時，可能會導致混亂。 在考慮這些問題對業務的影響之前，我們故意先關注客戶的問題。 如果您要解決的是業務問題，請務必將其直接與客戶問題聯繫起來。

3. 誰有這個問題，有什麼工作要做？

當客戶的期望與他們的現實之間存在差距時，就會出現問題。 您需要定義您關注的期望和經驗，以及他們試圖實現的結果。

4.關注問題的嚴重性

問題影響了多少客戶，他們受到的影響有多大？

“很多時候，問題陳述都是蓬鬆而高層次的”

5. 跟隨影響

在 Intercom，我們預先指定成功指標作為問題定義過程的一部分。 這讓我們知道我們應該注意哪些關鍵的客戶行為變化，以確認我們已經解決了問題。

6. 具體

很多時候，問題陳述都是蓬鬆而高層次的。 在您的問題定義中達到足以幫助您找出解決方案的具體程度非常重要。

7. 確定問題範圍

問題通常是有層次的，根據您的客戶和產品，它們可以被觸手。 分解您的問題以增加對每個維度的關注非常重要，而且您可以將其映射到您的解決方案選項並確定最適合的解決方案。

我們使用模板作為指南，以確保每個人都遵循通用格式，但該文檔通常伴隨著許多其他地方的背景研究。

“隨著我們在此過程中以及最重要的是在我們發貨後了解更多信息，我們會更新我們對問題的思考”

問題定義是基礎。 從那裡開始，我們的原則作為一個系統協同工作，將我們從問題推向解決方案。 隨著我們在此過程中以及最重要的是在發貨後了解更多信息，我們會更新對問題的思考。

我們採取全團隊的方法來解決問題

在 Intercom，我們都是具有不同專業的產品人員。 產品經理可能擁有問題定義，但每個人都有責任挖掘、理解並讓自己對實際解決他們面臨的問題負責。

這為問題定義的方法提供了信息。 這意味著讓更多的人參與研究，並分享採訪和見解以建立共同的理解。 人們可能需要一些時間來適應這種方法並看到其價值，但努力加快構建效率和解決方案的準確性是非常值得的。

從問題入手可以讓對講機的工程團隊設計出更周到、更合適的解決方案。 您對我們在 Intercom 的工作方式感興趣嗎？ 詳細了解我們的工程團隊。