8年產品實戰(zhàn)經驗教你如何通過結構化思維提升產品能力

4 評論 6747 瀏覽 100 收藏 23 分鐘

作為產品經理,核心素養(yǎng)之一是具有邏輯思維和結構化思維能力。邏輯思維和結構化思維可以幫助我們輸出高效、高嚴謹性、場景覆蓋面更廣的需求。這種思維方式是能夠被刻意練習并獲得正反饋的,能夠在工作中廣泛應用。具備邏輯思維和結構化思維能力有利于提高個人影響力以及在工作中的溝通表達效率,而缺少這種能力將導致信息傳遞不暢、浪費他人時間、影響說服力等問題。因此,作者認為應該養(yǎng)成早期意識,刻意培養(yǎng)自己,形成核心競爭力。

作為產品經理,我們經常會面臨邏輯思維的探討。

產品經理輸出的每個需求,需要站得住腳的前提就是邏輯是否能站得住腳,能否符合產品思維,商業(yè)邏輯閉環(huán),這對于任何一個產品經理來講都是很基本的素養(yǎng)。

而我們本章節(jié),是給大家介紹,我們怎么用結構化的思維讓我們輸出的需求更高效,更嚴謹,考慮的場景覆蓋面更多。

邏輯思維和結構化思維核心影響你與他人的關系,影響信息傳遞效率,影響你的個人影響力,是非常顯性化的兩種思維方式,是其他思維方式的基礎。

顯性化是你只要刻意練習,你便能習得這項能力,并且很快在工作中應用得到正反饋,提高你的工作效率、加強你的溝通表達能力。

思考和表達沒有邏輯與結構,是種災難。核心不是讓自己怎樣,而是非常浪費別人的時間。

大家的時間都很寶貴,你浪費了別人的時間,別人怎么還會有耐心信任你。尤其是對領導,你應該常常想幾分鐘內還沒把事情講清楚,他就沒了耐心。同事之間溝通也如此,你講了幾分鐘,對方還聽不懂,那么他下次就不再想跟你溝通。

同樣一件事情,能有邏輯地結構化思考和表達,可以節(jié)省雙方更多時間,提高效率。

邏輯與結構化思維可以讓接受信息的人快速明白你要講什么,也可以把你想表達的重點傳遞給到對方,它讓我們在溝通交流中提高自身說服力。

產品經理首要學習這兩種思維方式,邏輯思維提高自身說服力,結構化思維提高信息傳遞效率。

越早期越有這種意識,刻意培養(yǎng)自己,越能較早形成自己的核心競爭力。

一、應用場景:需求池管理

對于產品經理來講,一個新入職的產品經理留下第一印象的方式就在于對需求的管理和編寫,是否一針見血至于能夠讓需求羅列井井有條。

而一個產品經理的等級往往也是通過需求池的管理可以體現出來,本人認為需求池的管理是有下限的,但天花板并沒有。

如果讓你的需求清晰易懂,一目了然,追蹤溯源,通過需求池管理完成版本記錄,用戶故事的編寫等等,都是給業(yè)務方和開發(fā)人員大大提升信任度的手段。

產品工作流的唯一標準,能夠高效管理每個需求的生命周期

通過結構化思維可以對產品的工作流進行科學的梳理,提高需求池的協同效率之余,也方便查找和記錄每個需求的版本,方便新老交接。

  1. 產品需求的制定
  2. 優(yōu)先級排序
  3. 計算產品資源投入產出比
  4. 版本迭代計劃
  5. 團隊人效
  6. 緊急需求插入時盡量少的影響原產品計劃
  7. 有助于跨系統(tǒng)開發(fā)的關聯功能設計
  8. 提高項目跟蹤的準確性 – 需求跟蹤信息管理

二、有助于邏輯思維培養(yǎng)的工具

1.1 SWOT的技術策略參考——需求池的根基于產品需求模型的打造

分享本人在手機維修行業(yè)的一個利用SWOT分析法進行產品需求模型打造的一個案例。具體得出的結論和策略就不方便和各位透露,只是通過方法簡單羅列一下各維度的關鍵點,至于如何使用方法其實都是很靈活的,僅供參考。

以下是給讀者參考的手機維修行業(yè)需求模型案例:

1.2 四象限的靈活多變

四象限法則是時間管理理論的一個重要觀念是應有重點地把主要的精力和時間集中地放在處理那些重要但不緊急的工作上,這樣可以做到未雨綢繆,防患于未然。

往往大家都過于局限在所謂的重要,不重要,緊急,不緊急當中。

SWOT分析法已經提到過,方法是給人用的,一定是相對靈活才有實用性。四象限法則更是如此,接下來我給大家分享一下我是如何使用的。

以下是提供給讀者參考的四象限方法的使用方式:

優(yōu)先解決大用戶量的高頻問題,特別是在產品早期,一定要先解決用戶量大且經常發(fā)生的,提升基礎體驗,增加產品的穩(wěn)定性。最后解決少量用戶的低頻問題。

此處我定義的四象限為用戶頻率高,低;功能滿足度高,低。

  • 重要且緊急:用戶頻率高,功能滿足度高
  • 重要但不緊急:用戶頻率高,功能滿足度低
  • 不重要但緊急:用戶頻率低,功能滿足度高
  • 不重要不緊急:用戶頻率低,功能滿足度低

通過第一點得出的需求,又可以結合通過開發(fā)時間和四象限中最重要且緊急的為優(yōu)先開發(fā)見效快且開發(fā)難度不大的,這就是迭代,最后做很費勁而且見效慢的,這可能是未來的機會。

此處我定義的四象限為見效快,慢,開發(fā)量大,小。

同理可得,通過這樣的方式,我們就可以很好的完成對優(yōu)先級的排序。

1.3 敏捷管理

需求池遵循DEEP規(guī)范,通過敏捷管理的方式對需求池管理,能夠有效的保證項目通過最小版本增量迭代的方式進行產品設計;有利于快速迭代、快速響應以及快速調整,通過DEEP規(guī)范編寫每個需求的用戶故事即通過一段話體現出該需求的商業(yè)價值。

以下是提供給讀者參考的敏捷管理的使用方法:

1)敏捷管理的核心是盡早且頻繁地交付小批量的可工作的產品;根據(一)得到的新變化和信息,對產品進行恰當的調整。

我們使用敏捷管理的方式最直接就是摒棄人天和周期的概念,以工時去管理團隊人員的人效。

也因為要用工時計算,就自然而然的會把一個功能模塊拆解多個版本的需求進行快速的增量迭代。

許多自稱敏捷的組織,他們提前計劃了大量功能列表——通常提前一整年,并告訴團隊要以小批量的方式交付。

這不是敏捷,這是增量瀑布。

2)敏捷開發(fā)的核心特征是小批量地交付可工作的產品,從早期迭代中獲得洞察力,并在后續(xù)迭代中進一步完善和優(yōu)化相同的功能。

其中的關鍵在于我們無法預知和確定什么是可行的,什么是行不通的,這需要洞察和跟蹤數據。

打造一款優(yōu)秀的產品,我們要一邊走,一邊制定計劃。這與一年長的甘特圖完全不同。

「Now-Next-Later」只有與團隊自主權相結合時才有意義。這樣才能使團隊發(fā)現計劃的調整空間,及時做出應對。

想要靈活地工作,在做計劃時要注意建立高度靈活的路線圖、留出充足的彈性空間用于響應調整,以及獲得領導層的積極支持

利用好這三點,就可以持續(xù)地引導項目,而不是在前期就將它固定下來。這就是敏捷真正的意義所在。

而我們在每個需求都需要進行一個簡單的用戶故事描述,即:誰要用一個怎么樣的功能達到怎么樣的目的或價值。

三、邏輯思維的實際應用場景

3.1 高效且準確的收集產品需求

3.1.1 通過用戶反饋關注什么?

  1. 發(fā)現自己的問題
  2. 發(fā)現競品的問題
  3. 通過用戶反饋發(fā)現可能的機會點

3.1.2 通過哪些渠道來收集用戶反饋?

公開渠道:App store 、新浪微博、百度貼吧、七麥、酷傳網、雪球等。

  1. 公開渠道我這次主要以七麥為主,通過信息總覽,大致歸納典型的反饋方向:瀏覽近3個月用戶評價和版本相關信息,整理篩選出一些典型的反饋問題。重點篩選出差評、有實質性內容的評價和異常行為
  2. 微博:通過關鍵詞搜索,了解熱度較高的反饋及討論細節(jié),通過關鍵詞搜索全站,瀏覽B站官網近3個月的更新,重點關注高贊和高評論數的內容
  3. 百度貼吧:通過關鍵詞搜索,了解熱度較高的反饋及討論細節(jié)

半公開渠道:朋友圈、微信公眾號的文章、微信群、用戶評價。ps:如果想獲取競品的可以成為種子用戶或者是付費用戶。大家可以結合自己的產品性質,去不同的地方搜集哈。

內部渠道:用戶投訴、電話錄音、客服咨詢。別人家的咱們獲取不到的哈,如果能獲取到那也是犯法的,這種事兒咱不能干。

3.1.3 用戶反饋不同渠道的處理策略?

  • 公開渠道:勤搜索、關鍵字+收藏夾、使用監(jiān)測工具
  • 半公開渠道:定期搜索關鍵字、定期分析用戶評論
  • 內部渠道:整合內部用戶反饋渠道,定期與一線的同事溝通,或者是自己主動去一線

總之,去用戶量最集中的地方, 定期的去收集用戶反饋,會讓你的工作事半功倍。

3.2 判斷需求真?zhèn)危ㄍㄟ^產品角度以及用戶角度的分析)

3.2.1 用戶角度

俞軍老師的用戶價值理論很適用于 C 端產品:

用戶體驗 = 新體驗 – 舊體驗 – 替換成本

用戶價值理論只是提供了決策的思路,提升個人預測的準確性和決策的質量。

在 B 端戰(zhàn)略性需求的規(guī)劃,大方向上還需要考慮:

  1. 是否符合產品長期規(guī)劃,有效賦能
  2. 是否通用能夠滿足大部分B端用戶
  3. 是否能購平臺標準化

這三條可以作為 B 端產品設計的原則。

大多數產品不是死于需求做的太少,而是做的太多,超出了產品的邊界越做越臃腫,迭代困難。

需求的規(guī)劃需要從產品的定位著手,打造自己的核心賣點,服務于業(yè)務的北極星指標。也需要通過標準化設計攤平研發(fā)成本,低成本服務更多的用戶。

3.2.2 產品角度

  • 業(yè)務需求背景是否清晰:確保業(yè)務需求背景清晰明確,以便團隊全面理解業(yè)務目標和用戶需求
  • 是否符合產品定位:確保需求與產品定位一致,符合產品的核心價值和定位策略
  • 投入產出比是否合理:對需求進行評估,確保投入的資源(時間、人力、成本)與預期的產出和價值相匹配,確保合理的投入產出比
  • 是否符合平臺標準設計規(guī)范:確保需求與平臺的設計規(guī)范和標準相符,以保證用戶體驗的一致性和符合平臺的設計原則
  • 需求是否存在不可抗力風險,考慮平臺是否能夠承擔風險:對需求進行風險評估,考慮可能的不可抗力風險因素,例如技術限制、法律法規(guī)要求等,確保平臺有能力承擔這些風險并采取相應措施

這些問題是在進行需求評估和規(guī)劃時需要考慮的重要方面。通過綜合考慮這些因素,可以確保需求的合理性、可行性和符合平臺的要求。

3.3 小結

當我們在做真?zhèn)涡枨蟮呐袛嗟臅r候,要圍繞以下三點進行考慮

  1. 保證產品決策的質量
  2. 滿足產品定位不受影響的前提條件下,制定出符合用戶價值與商業(yè)價值的解決方案
  3. 產品的價值在于向人性的妥協或者改變用戶的習慣,需求亦是如此,管理用戶預期或者給予用戶新鮮感

四、進行團隊管理

通過結構化思維進行團隊管理,知人善用,讓大家都參與進來。

我認為需求池管理從來都不是master一個人的責任。

需求池的目的是讓團隊的產品經理能夠高效的完成協同工作,信息透明,清楚各自的工作以及相互穿插的工作對應的關聯關系,同步清楚組內成員各自項目的迭代計劃,產品生命周期等。有利于團隊互相借鑒,溝通交流,形成良性的競爭關系。

而在我的團隊,一般都會給團隊成員各自負責一個板塊進行主導,培養(yǎng)各自產品owner的意識之余還可以讓團隊成員都有機會熟悉其他項目,方便接手。

需求池的拆解 – master

需求估時合理性評估 – 高級產品經理

需求池的需求是否具備產品迭代計劃 – 成員1

需求池的需求評審記錄 – 產品助理/產品專員

需求評審會后意見反饋文檔編寫以及收集 – 初級產品經理

需求池需求梳理 – 成員2

項目迭代進度跟進 – 成員1

BUG池管理 – 成員1

合理的時間能夠提高評審會的效率。每日站會匯總,周會復盤,周一內審會,周四技術評審會。

4.1 每日站會匯總

以下是一種可以結構化報告進展的方式,涵蓋了研發(fā)、測試、產品、設計和個人任務的進展情況:

研發(fā)任務進展:

  1. 詳細列出研發(fā)團隊正在進行的項目或任務
  2. 提供每個項目的進展更新,包括里程碑的完成情況、功能開發(fā)進度等
  3. 強調任何可能影響進展的問題或挑戰(zhàn),并提供解決方案或建議

測試任務進展:

  1. 概述測試團隊正在進行的測試活動,例如功能測試、性能測試、用戶驗收測試等
  2. 介紹已完成的測試任務和測試結果,包括發(fā)現的問題和解決方案
  3. 強調任何延遲或問題,可能影響測試進度,并提供解決方案或計劃調整

產品任務進展:

  1. 著重介紹產品經理和相關團隊的工作進展
  2. 提供產品規(guī)劃和優(yōu)先級的更新,包括新功能的開發(fā)、現有功能的改進等
  3. 強調關鍵決策、用戶反饋或市場變化對產品任務的影響,并提供相應的計劃或調整

設計任務進展:

  1. 概述設計團隊正在進行的任務,如界面設計、用戶體驗改進等
  2. 提供設計階段的進展更新,例如草圖、原型、視覺設計等
  3. 強調任何與設計相關的挑戰(zhàn)、需求變更或迭代,并提供解決方案或計劃調整

個人任務進展:

  1. 列出個人正在負責的任務或項目
  2. 提供個人任務的進展情況,包括已完成的工作、遇到的挑戰(zhàn)以及解決方案
  3. 強調個人成就、學習和成長方面的進展,以及與團隊的合作和協作情況

請注意,這只是一種報告進展的結構示例,具體的內容和格式可以根據團隊或組織的需要進行調整和定制。

確保報告中的信息簡明扼要、準確清晰,并提供必要的上下文和關鍵指標。這樣可以使讀者更好地了解各項任務的進展情況,并采取適當的行動。

4.2 周會復盤內容

  1. 會議目標:復盤每周 Sprint 的目標、要完成的工作范圍(注意明確 Definiton of done),制定下周團隊需要完成的需求
  2. 一個完整的 產品 Backlog = 估點的用戶故事+ 優(yōu)先級 + 驗收標準
  3. 產品 Backlog是一個敏捷團隊管理開發(fā)過程的核心
  4. 制定下周工作的OKR,對OKR進行拆解成需求
  5. 制定需求評審,產品驗收,功能上線計劃

4.3 周一內審會結果

  1. 通過上一周OKR拆解得出的需求,由master統(tǒng)籌安排團隊進行業(yè)務需求以及產品需求的內審
  2. 通過內審明確需求的真?zhèn)涡?,?yōu)先級,覆蓋面(需求所涉及到的系統(tǒng))
  3. 業(yè)務需求部分輸出內審結論給對應業(yè)務方進行反饋,給出產品計劃
  4. 產品需求部分輸出產品計劃,同步開發(fā)
  5. 需求對應責任人,對應估時,完成當周人效評估

4.4 周四技術評審會

  1. 周四根據產品計劃,開展需求評審
  2. 收集評審會的意見在周五進行修改,同步業(yè)務方
  3. 技術針對產品計劃,給出對應的排期,同步業(yè)務方
  4. 業(yè)務需求需要業(yè)務代表人在場
  5. 輸出產品文檔,確保開發(fā),測試,設計明白業(yè)務背景和產品邏輯,以免無效溝通

細心的朋友可能會發(fā)現,我們團隊針對這四會,都會有5個重點要求,無論做什么都會有目的,都需要有結果。作為產品經理更是如此,對于需求池的管理從來都不會只是紙上談兵,更重要的是注重效果。

通過5個工作要點來保證每個會議的質量,減少溝通成本之余也能讓我們在會議的時候有方向和充足的準備。

五、總結

產品經理需要具備兩個能力,我們以往都在聽行外行內的人在講邏輯思維,但是我們要清楚,能力是需要用在正確的地方。邏輯思維放在需求池管理里面,往往就會搞得很臃腫。

邏輯思維的用處就是在產品設計周密度以及需求文檔編寫的條理性體現出來,而本章節(jié)更注重產品的結構化思維能力。

結構化思維是一種從整體到局部、從框架到細節(jié)的思維方式。它要求思考者不先入為主,不會過快地陷入細節(jié),而要經常留意事物的整體框架,在框架的基礎上去拓展細節(jié)。

因為人和人之間信息差,結構的越上層,彼此之間信息差越?。唤Y構的越下層,彼此之間信息差越大。

如果一上來陷入到最下層的細節(jié)之中,對于需求池的管理是非常麻煩的,而且大家的信息獲取成本就會很大。

因此,產品經理需要不斷鍛煉結構化思維,不斷的進行歸納和總結,養(yǎng)成做任何事都進行階段性總結和復盤的習慣是訓練結構化思維的核心。

思維如果懶惰任何種方法技能也無濟于事。

本文由@樂少有話說 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 干貨,高手?。?/p>

    來自江蘇 回復
  2. 謝謝老師的分享~我最近也在鍛煉自己的邏輯思維能力和結構化能力,我是這樣做的,您有空時能幫我看看這個方法是否可行嗎?
    1)提煉中心思想——從一些博主的文章,比如您的這篇文章,按結構梳理出您文章的框架,總結您的論點論據
    2)嘗試自己以一個主題輸出文章

    來自廣東 回復
    1. 最容易訓練的方式就是工作中,先從需求開始,每一個需求都是以從上至下,按層級進行產品設計,這樣是比較貼地的對結構化思維應用到實際場景的做法,當這個動作都變得比較規(guī)律的時候,就可以以功能模塊進行劃分,功能模塊也形成規(guī)律了,那就可以從系統(tǒng)框架去思考里面每個功能模塊的組合,去定義它的標準化,你也可以去關注一下我之前的一篇文章,通過產品體系去對產品設計進行規(guī)劃

      來自廣東 回復
    2. 這樣也是可以的,還可以將競品的框架用腦圖做出來;
      另外,自己做功能時候將樹干-樹枝-樹葉列出來;
      日常遇到事情刻意多想幾個方案出來;
      慢慢形成結構化和系統(tǒng)化思維方式

      來自湖南 回復
专题
12713人已学习14篇文章
现在,不少企业和行业都走上了数字化转型的征程。本专题的文章分享了数字化营销策略。
专题
18654人已学习12篇文章
如何设计出一个抓住他人眼球的feed流 ?feed流的组成元素以及常见的feed流样式?本专题的文章提供了对于feed流设计的思考。
专题
52896人已学习18篇文章
做了好多年的产品经理,该不会连注册登录功能设计都没整明白吧?
专题
16346人已学习12篇文章
本专题的文章分享了数据的分析方法。
专题
13937人已学习13篇文章
本专题的文章分享了WMS系统设计指南。
专题
31910人已学习17篇文章
你只知道它火了,却不知道它背后的内容营销秘籍。