項目從0到1覆盤總結：產品的靈魂是「故事」
畢業一年多，能參與一個產品0-1的過程是很幸運的事情，也是收穫非常的經驗之旅。
看過我之前文章的同學會知道我是從研發工程師轉產品的，轉產品的過程並不容易，面試過程磕磕碰碰，最終相上了現在的公司，屬於智能領域的。離上一篇總結的筆記已經過去大半年了，一直想說寫一篇比較“深”層次的文章，是檢驗和鍛鍊自己的一個方法。文章內容多半是給自己回顧和總結的。歡迎品嚐，褒貶不諱。
以下將從以下幾點進行總結：
- 如何獲得這次機會
- 產品經理的必備技能：調研、戰略及定位、立項、開發進度與需求管理
- 產品經理的推力：市場與銷售的支持
- 重新認識產品經理
1. 如何獲得這次機會
作為一個剛入職不久的產品新人，剛進入公司後負責的第一個比較完整的產品是對公司官網的重新改造。為了更好地完成這次迭代，多次跨部門與市場和銷售部門對接需求，通過閱讀《增長黑客》讓自己在設計網站的過程中思路更加清晰，結構也更加流暢，同時對埋點也更為重視。為了讓站點的文案效果更佳（把官網的產品諮詢量提上去），加班回家後依然炳燭夜讀了《文案訓練手冊》。
項目上線後各方面反饋都不錯，在日常的工作中勇於負責，自我驅動力強。我想應該是基於這些表現，為自己把握住了負責新產品的機會。整個過程下來感覺自己對產品的基礎流程算是走通了。但第二個完整的0-1項目才讓我對產品經理有了更多的鍛鍊和感觸。
2. 產品經理的必備技能
2.1 調研
產品在決定要不要做以及如何做，都需要通過調研。當然還有一類是領導決定要做這個項目。無論怎麼樣，產品經理依然需要進行調研和需求處理。
前期的調研首先要進行市場劃分，確定主要調研對象再進行需求調研。市場細分是需求調研的前提，需求調研的主要目的是為了避免閉門造車。進行市場細分時，可以請教市場部和銷售的同事一起討論，看現有的客戶中是否有與新項目客戶群重疊，關聯度高的則可列入調研群體，可以省去很多工作。
調研的過程要十分注意一點：客戶不能幫我們設計產品。很多時候他們會跟你描述為遇到了什麼問題，他們是如何解決的，導致最終我們獲取到則是關於“解決方法”的描述，而需求調研者經常陷入這個蜜糖陷阱中。成功的方法可以作為參考，但更多的是要多問幾個為什麼，追溯更深層的需求動機。調研的方法如何選擇則不在此作為討論。
我們的項目是平臺的產品，1.0版本主要是合同客戶。前期先通過市場的需求分析得到了需求框架，而後再跟合同客戶進行需求的細化對接。由於地域上的問題，更多時候是在即時通訊上與用戶對接。大家都瞭解b端的項目，很多時候產品的使用者其實不是決策者。這不僅會影響到需求調研的結果，還會影響到產品定位以及後續的市場文案、銷售等環節。
調研決策者可以瞭解她們為什麼購買，期待達到什麼目的。調研使用者可以瞭解產品哪些方面好用不好用，哪些方面不足等等。決策者通常會偏向關注產品能幫助他們的企業提升哪些效益，而使用者會更偏重於產品功能與體驗上的描述。
2.2 產品戰略與定位
產品定位是產品經理在大量的市場調研的基礎上逐步加深對市場和用戶需求的理解，最後在用戶需求和市場趨勢中找到契合度最高點的過程。產品定位如果是產品經理坐在辦公室拍腦袋想出來的，那都是“床前明月光”。準確的產品定位是產品成功的核心。
產品定位不僅是要找到自身的優勢，還是尋找論據的過程，同時也是給競爭對手定位，而非一味地互相模仿。產品定位和戰略有部分重疊，但戰略會融合市場和公司戰略，產品定位偏向於產品核心功能和技術。
2.3 產品立項
產品立項要更留意的是關於開發進度，里程碑，技術壁壘以及是否需要第三方平臺審核。看似短短的一句話，如果沒有處理好，後續可能得花10倍以上的工作量作為代價。這點在我剛負責的項目裡，已深有體會。特別是平臺審核的坑。
2.4 開發進度與需求管理
開發進度控制
產品在立項時就該定好各個階段該做什麼事情，進入研發後要跟蹤好開發的節奏。研發的過程還要考慮人員離職帶來的影響，系統bug以及返工等不確定因素。
需求管理
產品是一個需求的集合體，需求管理是產品全週期需要慎重處理的一件事情。建立需求池的其一的初衷是幫助產品經理和開發以及所有相關團隊成員來確認產品工作任務的，另外一個是來做版本控制。
可以通過需求卡片或者需求池來存檔。需求卡片可以幫助產品經理自身更好的理順這個需求的來龍去脈，同時也方便產品經理自身快速地“轉譯”成需求文檔給開發團隊，需求池是一個集合。需求管理建立起來後，更重要的是對需求的跟蹤。如果某個需求被停止或者暫緩等情況，需要及時地備註說明並且郵件通知所有相關人員，確保需求跟進流程都有一個輸出結果（驗收標準等）。有時候還可以參考“用戶故事（user story）”的形式來描述。
3 產品經理的推力
3.1 市場支持
產品在進入開發階段時，產品經理還得配合市場部進行產品前期（導入期）的產品推廣工作，這時候可以簡要說明該產品要上市、定位產品等先引起市場關注。到了成長期產品開發也到了尾聲，這時候可以進行產品特點的介紹，讓更多的用戶對產品產生興趣。產品經理需要提供與產品相關的產品介紹、功能賣點等詳情給市場部的同事，在文案定下來過程中還得進行反覆修訂。
這個過程會涉及到文案的一些要點，但始終要記得使用用戶的語言來描述，建議多用數據來說明。數據是從需求文檔和測試報告中來的也不是胡編亂造的。如果實在沒有，可以結合自身產品定位，參考下競品。關於產品資料的描述，有一句話說的特別好“試著把產品名稱換成競爭對手的名稱看看是否行得通，如果同樣適用，那麼這則文案就是失敗的”。站在用戶的角度去思考，告訴他們我們的產品能幫他們解決什麼，而非我們能做什麼。產品資料是給用戶看的，是要讓用戶看完後購買我們的產品，而非炫耀技術、自我滿足和陶醉。
產品成熟期則可以更多介紹一些成功案例，迭代期可以多一些品牌上的宣傳培養用戶對產品的忠誠度。
關於文案的更多幹貨推薦大家看一本《文案訓練手冊》，看完一定會有超出驚喜的收穫。
3.2 售前支持
對於銷售部而言，銷售人員關心的是如何幫他們完成銷售任務。但銷售並不是銷售同事自身的目標，準確的說是產品的目標。產品經理有義務協助銷售同事更好地銷售我們的產品。在產品培訓時，可以準備一份ppt等文檔或者必要時可以準備一套考題。
售前支持在產品1.0發佈後，產品經理需要支持的工作量也是最大的。產品經理可以針對不同的對象準備不同的資料，針對銷售的話也可以準備一份《產品介紹》文檔以及成功案例。發給銷售人員的產品介紹文檔可以通過類似這種標籤描述“key：用戶需求，value：產品功能”適配地告訴銷售人員。同時產品經理在與不同對象溝通時，需要用不同的方式和方法，也可藉助不同的工具和文檔等。後續的許多需求和市場反饋都得跟客服人員和銷售以及市場部的同事進行跟進。
4. 寫在最後
4.1 重新認識產品經理
項目從0-1的過程，產品經理是有許多工作要參與的。從銷售、客服、客戶那裡瞭解市場需求和趨勢，綜合分析產品需求，明確產品的發展方向立項開發。負責產品營銷的整個過程，保證產品的市場成功，具體表現在銷售支持、市場營銷等方面。這個過程，產品經理就像一個齒輪或者中間件，需要通過切合的角度來保證產品從研發到交付使用的過程中沒有障礙。
4.2 產品經理務虛能力
“務虛”不等於“忽悠”。
務虛與忽悠的區別在於他是可以通過務實的工作能最終實現的事情。
我們在日常的產品工作做成中會時常遇到這麼一種情況：競爭對手在市場宣傳過程中會提出一些比較新穎的概念，我們銷售人員會經常直接拿來套用到自己的產品上，免費幫競品宣傳，接著還不斷地跟產品抱怨或質疑我們的產品。我們的產品經理雖然都指著解釋道這些都是概念的東西，但內心也是很焦急如何結合公司和產品的定位提出一個與我們更貼切和相關的概念，反饋給銷售人員，進而宣傳我們自己的概念。
有務虛的能力也一定要匹配務實的幹勁。務虛是相對於決策的環節而言，對事物發展規律與走勢的宏觀把控，而務實則是將決策執行為現實可行的過程。正確地務虛不應是東施效顰，應該明確出發點並根據自己的能力和立場去設定。寫到這裡不經又想起了喬布斯老前輩。
產品經理做到一定的程度，其實已經掌握了一種內在的感覺和邏輯即務虛能力。這是一種綜合能力的體現，他綜合了人性心理和行為以及市場趨勢的洞察力、對技術趨勢的判斷力。通俗地說，就是一種畫大餅的能力。但然會務虛也一定要懂得如何務實，從而達成產品戰略目標。這是一種心有猛虎細求薔薇的個人魅力。
4.3 b端產品認知
- c端用戶是上帝，b端客戶不等於用戶；
- c端的用戶群體可以進行各類人性需求／畫像琢磨，心理描述。而b端則更注重業務流，工作效率等等（業務流程整合，提高工作效率等）；
- b端產品最終目的是幫助企業去完成“生產”，他的成功不僅僅取決於用戶體驗上，更重要還是在於能否幫助企業“成功”；
- b端產品只是買賣的第一步，服務才是這筆交易的核心。產品還需要關注公司內部銷售團隊、客戶方的營銷團隊，還需要站在完整的產品生態中不斷汲取時勢更好的服務客戶方；
- c端圍繞著用戶迭代產品，b 端產品還需要站在管理層的角度來驅動產品（員工工作量／工作效率等）；
- b端，產品業績上不去，過程做的再好，也無法得到認可，不可能在公司內部產生威信，而產品經理是非常需要威信的；
- 做b端項目，同樣要以用戶為中心，以市場為導向。對客戶要尊重，對市場要敬畏。
最後摘抄一段話來結束本次的覆盤總結：
“產品的靈魂是故事。這個故事在各個層面的含義是不一樣的。在需求層面，故事就是客戶要解決的問題；在開發層面，故事就是研發設計、調研的故事；在推廣層面，故事就是拿下一個個重要的單子，與競爭對手的競爭，以及寫文章、策劃廣告；在銷售支持層面，故事是與銷售人員一起跑客戶，一起並肩作戰。所有層面的故事串起來，就是一個產品經理的故事。”
附日常整理的乾貨：
1.那如果在開發過程中“想”改個設計，怎麼辦？
（1）學會評估【需求迫切度】
對於目前版本來說是是否需要馬上做，還是可以放到下個版本。
（2）怎麼判斷呢？
如果這個功能不改，是否會使當前版本出現不可控的斷點和風險。比如1.0其實還不需要用到驗證碼，如果在1.0（用戶量較少）忘了設計時，其實可以放到2.0再實現的。
（3）非要改的情況下怎麼辦呢？
1.評估研發難度（plan a,b），再進行分解需求，分拆設計，拆成若干個簡單的功能，最後先實現最重要的，把暫緩的放入下個版本（節約工期）。
2.其他需要做的：
- 有責任感和使命感。勇於承擔責任，甩鍋是對項目的不負責，甩掉的也是別人對你的信任
- 明確地分析本次修改的原因。可從需求產生、解決了什麼問題、產品經理通過努力已經將影響降到了最低，有何意義等方面，讓自己明確該需求的同時也需要讓大家都明白，事情是團隊而非產品一個人在進行，大家都是驅動者。同時降低大家對本次修改的排斥心理。
- 總結。總結本次問題，才能不斷的驅動自己的成長，減少下次掉坑的風險。
2.如何判斷增加一個功能的必要性：
- 這個功能解決了什麼問題，解決之後達到的效果？（功能價值）
- 此功能主要使用的場景是什麼？（用戶場景）
- 競爭對手那裡是否有這個功能？（競品分析）
- 沒有這個功能的時候，用戶是怎麼去解決問題的？（可替代度）
- 新增此功能是否增加盈利模式？（盈利模式）
- 若新增功能的風險點，若發生風險後的相關預備方案？（風險措施）
- 當前是否有阻礙此功能實現的矛盾？（主要矛盾）
- 如果新增了功能，到達什麼樣的數據指標才算合格？（數據指標）
- 功能的複雜度，如果功能複雜是否需要分期迭代進行？（版本規劃）
如果是一個新產品，還需考慮成本、可調用的資源、及產品上線後如何進行運營等等……
本文由 @茶茶Aryan 原創發佈於人人都是產品經理。未經許可，禁止轉載。