在大多數人的眼中，產品經理不過是畫畫原型、寫寫文件罷了。其實原型和文件只能算是作為乙個產品經理最最基礎的必備技能。相對於紙面上展示的東西，解決問題的能力才是乙個產品經理必不可少的。
一、產品定位
如果我在還沒有找到前進的方向之前，就開始畫原型或者寫文件，這很容易就會導致我們開發出來的產品和我們原本想象的有偏差。
所以在做需求分析之前，我需要知道我們團隊要做的是什麼東西？是面向個體使用者還是面向企業？是面向怎麼樣的群體？使用者畫像是怎麼樣的？我們的產品能解決使用者的什麼痛點？現在市面上有沒有已經成熟的產品？我們的產品要怎麼做才能在市場上獲得一席之地？等等……
在一連串的發問之後，通過討論解答這些問題，我們可以快速找到自己的產品定位。
二、需求分析
需求的**有很多，在產品開發前期，決定產品需求的可能來自於老大或者老闆；當產品已經初具規模的時候，需求可能來自於一些競品或者是種子使用者；當產品已經成型並且走向市場的時候，需求可能來自於資料分析還有產品經理的產品創新。
所以要怎麼進行需求分析？在搜尋引擎上面可以找到很多答案，我這邊說一下我自己的方法。
三、制定解決方案
需求有了，優先順序也排好了，我就需要根據優先順序把需求轉化為解決方案了。
不同的需求有不同的解決方案，我舉個例子，如果這個需求是要做乙個全新的功能，那我會先做乙個mvp，也就是最小可行化產品。因為對乙個全新的功能來說，過度地討論細節可能會讓我們的這個功能變得十分臃腫，並且有可能因為考慮不周導致功能在邏輯上沒法形成閉環，所以我們先把最最基本的功能實現了，至少先把curd做了，然後再慢慢考慮其它功能。同時，這也是容錯率最高的做法，要是做完之後因為其它原因需要捨棄這個功能，那其中產生的時間成本和人力成本就是最低的。
這裡還是要講一下，關於對mvp的理解，這個在不同的產品上、不同的情況下見仁見智，因為我們的種子使用者大多數來自於我們公司的其它研發團隊，所以他們能夠用相對包容的心態來使用我們的產品。如果讓真實的使用者使用mvp的話，可能他們無法接受這麼簡陋又毫無誠意的產品。所以是否要做mvp，這要視實際情況而定。
四、需求評審
在很多時候，產品經理是沒有實權的，但是我們說這個功能做或者不做並不是用一句「我感覺」就能讓領導信服的。這時候我們就要把我們做好的解決方案拿出來，當然，還有原型工具繪製的線框圖那就更好了，也可以更加直觀地讓領導知道我們要表達的意思。
這裡要注意的是，我們應該先把需求實現的流程在自己的腦海裡走一遍，不然在開需求評審會的時候那是相當尷尬的。
五、原型與prd文件
這是作為乙個產品經理最基本的技能，是畫低保真原型還是高保真原型，是做詳細的prd文件還是簡單寫寫備註，這個看專案而定，這裡就不再贅述。但是最重要的一點就是，要讓開發人員知道怎麼開發，不然就完蛋了！
六、跟進開發
開發總是需要一段時間的，在這段時間裡，產品經理肯定不是一直閒著的。比如我們團隊一次迭代需要兩個星期左右，那我可能會拿一部分時間準備下次迭代的內容，再拿一部分時間跟進開發。
在乙個模組開發完成之後，我就會問下開發，能不能把做出來的東西給我先看一下。即使原型有了，文件有了，開發出來的東西也有可能和我想象中的不一樣，這就需要我在開發過程中與開發進行溝通。這裡可能就少不了諸如「你原型上不是這樣子畫的啊！」、「這和你之前說的不一樣啊！」這樣的唇槍舌劍。遇到這種情況的時候，我的建議就是不然就是苦口婆心慢慢相勸，不然就是平時多做點俯臥撐。
總之，我們不能在所有功能都開發完成之後再去看開發結果，而是必須在開發過程中就一直跟進開發並且和開發及時溝通，這樣最後做出來的東西才是我們要的，同時也可以避免專案延期和加班。
七、測試
在沒有專業的測試人員的情況下，產品經理就是最好的測試。那這裡需要和開發達成的協議就是，提測之前必須完成自測，不然產品經理真的可能測到一半就測不下去了。
說到測試，編寫測試描述的最好時機就是在編寫使用者故事的時候，我會在故事卡的背面記錄如何測試故事的一些提示語句。寫這些測試描述的目的是傳遞故事的額外資訊，開發人員也可以更好的了解使用者故事。這裡的測試描述可能是簡短的或者不完整的，我會在開發結束之前將測試描述轉化為測試用例，然後在根據測試用例進行測試。
一、事情雜、亂、多
產品經理每天的事情很多，可能我正在做方案，開發也要找我了解一下需求，那麼這一來而去我就會忘記今天還有什麼事情沒做了。所以對於產品經理來說，制定計畫是非常重要的。
比如我在每月的1號先制定未來乙個月的迭代計畫，在每週五更新需求池，在每天上班前十分鐘先把今天要做的事情寫下來。有了這些自己定下的規矩，就可以避免因為事多而忘事的情況了。
二、 需求理解偏差
需求不明確的點沒有及時溝通，導致在迭代快結束的時候才發現開發出來的功能和我想象中的功能不一樣。
對於這個問題有兩種解決方式，一種是從源頭出發，加強對自己所寫的使用者故事的顆粒度把控，確保產品、開發、使用者理解無歧義；另一種是在開發過程中及時了解開發進度，找到問題並解決問題，像我們每天都有一場5-10分鐘的站例會，我可以通過這個小會了解開發的進展情況，就能及時發現問題。
三、邏輯缺乏說服力
很多產品經理都是從一堆質疑聲中走出來的，主要原因在於設計產品時只走一條流程，把其它流程都忽略了。
一位資深的產品大佬說，要看這個產品經理是否合格，只要看他畫的流程圖上有沒有「否」字就行了。所以，我們在做產品設計的時候不僅要把主流程走通，還要根據不同的場景走通其它支路，讓自己的產品流程形成閉環，這才是正確的產品思維。
其實乙個產品從0到1完全沒有像文字表述得那麼容易，我永遠記得我們有次上線一直加班到凌晨的場景，其中的艱難不必多說，相信每乙個產品人都能夠深有體會。但是，要想成為乙個能夠獨當一面的產品經理就必須經歷這些過程，在從0到1之後，還要從1到100到1000到10000，這才是成長。
產品經理從0到1 高瑋
目的 歡迎我們到達網際網路的下半場 背景1 網際網路進入成熟期 背景2 人口紅利逐漸下降 主要矛盾 區域性供過於求 使用者審美和要求越來越高 要有網感 行業背景 網際網路開始增量競爭，對pm的要求更細分更高 必備傍身之物 模型 框架 方 市場 消費 真正的需求 投資的過程是產品 投資的物件不是產品 ...
如何從0到1實踐Cloud Native
3月25日，網易雲技術布道系列第三期 對話架構師活動在網易杭州園區舉辦，網易雲基礎服務總經理陳諤 美麗聯合集團研發部副總裁曾憲傑和51信用卡cto郭威分別從雲原生應用技術 技術人員的成長和技術對業務的價值等方面帶來了乾貨分享。本文將為大家重點解讀網易雲基礎服務總經理陳諤帶來的分享 cloud nat...
從調研到設計，換髮型產品設計的從0到1
乙個產品從無到有再到使用者手上基本都可分為3個大階段。第一階段 一定要想清楚產品做什麼。給b端使用者還是c端使用者，做工具型的還是內容型的，做交易還是做平台。主要使用者是誰，要解決ta們什麼痛點，這些痛點又是在什麼樣的場景下產生，用什麼樣的解決方案可行，跟現有的解決方案相比有何競爭力。eg 之前有過...