“我之所以還能夠對未來充滿信心，是因為我相信從0到1是一件盡管艱難但是有意義的事情！”

不久前，我在日記本里記下這句話來鼓舞自己，從2015年開始到2016年底，為了實現產品從0到1，我幾乎爬過了數不勝數的坑。我把它們記錄下來，希望同行看到后引以為鑒，也希望能夠從這些經歷中總結出一套普適性強一些的方法論來。

如果你還沒有準備好，請不要勉強答應

2014年8月，我來到現在的公司，以實習生的身份，公司成立剛好4個月。初來乍到，我的工作任務是打雜，沒錯，哪里需要我，我就去哪里?？头?，項目助理，運營人員等等，3個月內，我基本上把公司里所有的能接觸的活兒都做了一圈（那會兒體力真好）。當時還沒有畢業，覺得自己是有無限可能性的，職業規劃這個事情，那個時候是沒有什么概念的。

轉折點出現在2015年初，公司漸入佳境，準備要做一個APP產品，所以就開始滿世界找合適的產品經理。如果大家有經歷過，就應該知道一個又靠譜又便宜的產品經理有多難找，招人的工作非常難以進行，最后老板想了想，任性地決定讓我頂這個缺。其實也不能說找我頂缺是件完全沒有根據的事情，因為我大學是學計算機專業的，12年的時候有去實習寫C++，14年初又去實習過需求分析師，不管怎么樣，整個團隊里，我的過往經歷和產品經理的屬性相對是最匹配的。

“這是個挑戰，但是這種掌控不了的事情，聽起來還不錯”。我立刻就答應了，生怕老板反悔。

接下來我面臨的尷尬境地就是，居然沒有人可以指導我如何做產品。那個時候的產品開發是交給一個外包團隊進行的，因此也沒有開發人員可以來告訴我他們目前的項目進度。最可怕的事情是作為產品的負責人，一開始很多時候我對自己下的決定都表現出一種不肯定和不自信，身份的轉變也并不能讓我迅速適應這種轉變帶來的一系列其他影響。一個基礎為0的產品經理和一個基礎為0的團隊以及一個基礎為0的產品，我想這也是非常少見的吧。

我開始后悔接下這個活兒，但是這個自己給自己挖下的坑，含著淚也得往下跳啊。

產品從0到1，最需要判斷力和執行力

產品經理要做什么，具體怎么做，那個時候我都不清楚，我唯一知道的是，整個產品是由我來負責的，有一句話說，明白許多道理但還是做不好自己，足以形容這種窘境。

由于外包團隊在西安，而我在上海，很多時候溝通成了一個最大的問題，我往往很擔心我提出來的改進到底執行了沒有，到了哪個地步。

一開始我會以一天一更新的方式來要求開發團隊每天生成一個測試包發給我，但是很快發現一個問題，就是問題太多根本改不完，我加入的時候交付時間就已經非常緊張。有經驗的產品經理其實已經看明白，這個其實就是需求管理，我們需要從數不清的坑中選一個最致命的來填。

稍微明確了下現狀后，我調整了一下溝通方式，每天晚上我會拿到最新的測試安裝包，然后趕緊測試，測試結果寫成excel表格，我暫時叫作buglist，這就是我的第一個需求管理文檔了。我在buglist中規定了幾個簡單規則：

1. 寫清楚bug；
2. 標明bug的優先級；
3. 規定交付截止日期。

遠方的開發團隊拿到我這張buglist后，可以按照他們的分工來分別解決問題，每天交付給我的安裝包，修復情況也是按照交付截止日期里的規定來執行的。這里面有一個無法被避免的問題，那就是有很多bug，我明明確確地知道，是無法在規定時間內修改完的，能做的只有砍掉它們，心無旁騖，把最核心的事情做好。

這段經歷使得我一直認為，產品經理更多時候是一個承擔責任的人，想要擔得起這個責任，拋開專業性不說，判斷力和執行力是最重要的。

身為產品要重視結果，但是身為經理要重視流程

產品如期上線，當然問題還是很多但有了喘息之機。經過前面的項目外包經歷，老板也意識到，如果真的想要好好做一個產品，不能依賴于外包團隊，所以開始自己招開發團隊。幾個月內我們組建了一個集UI／產品／IOS開發／安卓開發／后臺開發為一體的小團隊，可以說是麻雀雖小五臟俱全。

于是我們馬不停蹄地開始對產品進行迭代，因為之前趕進度我砍掉了許多需求，現在我認為總算可以把這些缺憾彌補起來。我把我的想法和老板溝通后他表示同意，但是在和開發團隊進行溝通時我卻遇到了一些麻煩，因為團隊剛組建，我們的很多工作都還是基于各自以往的經驗，在相互溝通的過程中總有尷尬和不到位的地方。正是因為這些零零碎碎的磕磕碰碰，讓我原以為可以很快執行好的需求，總是遇到延期和執行不下去的問題。

我深知自己的專業度是不夠的，所以決定從兩個方面來建立新流程，一是基于團隊成員以往的工作習慣，二是參考目前常用的開發流程，當然，根據我們的實際情況，會有一些調整。

小團隊，所有工種就坐在離你不超過5米的范圍內，溝通基本靠吼，盡管如此，也還是得有自己的章程。為了方便大家理解，特地把我之前寫的產品部門工作手冊截圖展示下。

圖1-產品部門工作手冊截圖

篇幅有限，所以簡單介紹下流程：

1. 產品調研
2. 產品立項&原型
3. UI設計&交互設計
4. UI效果圖驗收
5. 技術方案設計&排期
6. 產品功能開發
7. 測試
8. 產品打磨&驗收
9. 發布上線
10. 數據跟蹤&迭代

這里沒辦法和大家詳細介紹每一個流程中的工作細節，因為那是因人而異各有所長的，就不在此獻丑了，想給大家分享的一點是我們實際工作中的溝通方式。前面圖中其實可以看到，產品定下需求后會出一個原型，務必強調核心功能點和邏輯合理性，畫原型的工具有很多，一一嘗試后我還是選擇使用老牌的axure作為主要的工具（原因后面會講到）。然后就是拉著技術和設計來開會講解需求，我一直相信專業的UI和技術在很多時候可以給到很好的建議來避免一些坑，這個會開完以后，技術（后端／前端）基本上可以理解需求中涉及到的數據邏輯，而設計也可以明確原型背后的實際需求。

接下來做的這件事情，我認為非常重要，那就是做排期計劃。

UI這邊會按照低保真原型（如果團隊有UI的話，盡量不要做高保真的原型，這樣會限制UI的發揮）來出效果圖，每個設計師習慣用的工具都不一樣，photoshop和sketch都是不錯的工具，其中sketch的使用門檻比較低，我建議產品經理也可以學習一下。一般來說，UI同學花1～2周的時間就可以完成一套完整的UI效果圖。

技術這邊，前后端的同事會分別按照需求提到的功能點做任務拆分和時間排期，這是負責后端的同事帶來的方法，叫做時間片管理。把需求中的功能點盡可能拆分成一個個任務片段，給每個任務片段分配時間（story），一個story差不多是2個小時。開發的同事可以按照story來分配自己的工作時間，平均1天可以完成3～4個story是比較合理的速度。有了這個方法，所有人都可以量化自己的工作成果，做出來的排期也相對比較合理。

與此同時，我會著手撰寫產品需求文檔，將包括頁面交互，全局變量，用例圖，排期等都寫到文檔中以便團隊成員共享。很多人喜歡用word來寫需求文檔，但是鑒于個人的使用習慣，我還是會用axure來寫文檔，一來方便共享和修改，二來也便于將前面畫的原型直接寫進來，大家就不需要存很多文檔了，前前后后只用到這一個。使用axure畫產品需求文檔的方法比較多，也不在此多做介紹了，大家嫌麻煩的話可以直接找我要模板。

產品開發驗收上線后，有一個特別考驗產品功力的就是數據分析了，做數據分析肯定得要有數據來源。有的團隊會自己在產品開發過程中就埋下一些監測點，建立數據模型，通過后臺來觀察。我們的情況是產品正常開發周期都已十分緊張，所以干脆接入了“友盟”來協助開發埋點和生成數據報表，好處是開發成本小且可視化效果好，缺陷是有時候不夠準確（這是統計規則不同的原因）。

到底是產品成就運營，還是運營成就產品

作為一個自認有產品經理堅持的人，我始終相信產品內在的自發傳播性，也就是說真正的好產品一定能在某個人群中找到它的存在價值。但是在現實中我也常常見到過很多內在品質不錯的產品，但是奇怪的是身邊都沒有人在使用它們甚至不知道它們。這也是為什么這個命題會存在，如果產品不好，運營工作很難開展，如果運營不好，產品就很難找到用戶，也很難存活下來，這叫“酒香也怕巷子深”。

對從0到1的產品來說，其實“活下來”是件比啥都重要的事情，這就決定了在產品設計之初，切入需求的時候，就得充分考慮產品存活難度，過度依賴運營規模的產品，其實嚴格來說不太適合資源不多的小團隊來做。所以，認準一個核心需求點，排除萬難，順便排除掉一些不切實際的想法，從產品的角度考慮問題，還得從運營能力的角度來評估，這也是為什么產品經理不是一個所有人都能做的崗位。因為你不僅僅是一個產品經理，你還得是一個運營，因為如果連你自己都沒有辦法做好運營的話，也請不要指望其他高人能幫你把這件事想清楚，你的產品，沒有人也不應該有人比你更清楚。

所以，如果你正在做一個產品從0到1的部署，我會誠摯地給一個建議：無論排期計劃是多么緊張，無論人手有多么的不足，也請先將產品運營規劃考慮到整個版圖中，因為在大多數情況下，找到你的用戶并用一個點子吸引他們，比完成你的產品更重要。

你可以不看書，但是你不能不學習

最后說一點，是關于產品經理的自我修養。大家都知道產品經理這個職業，屬于自己個人的時間真的非常少，很閑的產品經理嚴格來說是不夠稱職的，因為一個產品要操心的事情真的很多。盡管如此，我希望大家可以養成不斷學習的好習慣并將此作為自己職業生涯的技能之一。學習能力，很多人有，但是自我約束力大部分人沒有，而產品經理如果不能很好的和時代潮流，市場環境保持一致甚至領先的步調的話，很快就會被其他更會學習的人超越。學習的方式，很多人都說要看書，我現在也開始惡補許多，是為了強化自己的系統性，但是從實用性來考慮，網上也還有許多碎片化的知識，善于歸納總結篩選信息的同行們也可以在網上找到適合自己的學習方法，互聯網產品經理這個職業出現并不算久，很多東西也沒有非常標準化，希望大家能夠共同進步，思考，分享。

本文由 @路遙 原創發布于人人都是產品經理。未經許可，禁止轉載。