產品經理原型評審怎麼開

Ⅰ 初級產品經理-如何高效繪制AXURE原型

      原型是產品經理或者交互設計師所設計的某一需求或者某一問題的具體的解決方案。繪制原型的工具有很多，我們公司大多的產品用的都是Axure。用這個軟體，高保真或者低保真原型都能做的很好。那麼，怎樣的原型才適合團隊交流？

      畢竟繪制出來的原型並不是只給自己看的，還要講解給團隊里的成員，UI/前端/開發。特別是進行小組內評審的時候，通過演示原型，需要向他們講解產品內部的邏輯、具體的頁面、動效等，還要向他們詢問設計是否合理，能否實現等，靜心傾聽他們的意見。這時候，原型就是一個思維傳達的工具，將你的想法，翻譯並灌輸給你的團隊成員。同樣，原型是也團隊的交流工具，針對繪制出來的原型，每個人都可以談談自己的看法，交流思想，完善原型不足的地方。

      所以原型繪制出來，必須要有基本的交付標准。

一、原型設計的基本交付標准

1.清楚------讓他人能明白產品是干什麼的，包括什麼功能，有哪些頁面。

需要清楚地表達頁面有哪些內容模塊

需要清楚地表達模塊內部的構成元素

2.清晰------讓隊友知道具體有哪些要求，指導他們如何做

【1】功能操作

  某一個功能可以進行哪些操作，點擊/滑鼠懸浮/拖動等操作，以及頁面會有什麼反應。（方便開發的工作）。

【2】操作路徑

       有一些操作是要跳轉頁面，跳轉的路徑需要標清楚，跳到哪去了，涉及哪些頁面，頁面之間是如何聯系的。防止用戶迷失。

【3】點擊狀態

一些鏈接，按鈕，需要標明它初始的時候是什麼樣，滑鼠懸浮有什麼效果（顏色/下劃線/提示語等），點擊的樣式變化，以及點擊後的樣式。（這些可以為前端的工作提供方便）

【4】信息組合

相關的信息需要組合在一起，比如一些基本信息，姓名/性別/年齡等最好放一塊，不要分開。不相關的保持距離。

【5】位置排序

頁面的布局應該適應用戶的習慣，瀏覽方式、工作任務。突出強調重點，方便用戶的工作。一些數據可以思考一下它們的排列方式，按什麼排序，能方便用戶查找，仍舊是「以用戶為中心」。

3.周全-----產品的各種細節，不能疏忽

【1】交互狀態

     某些重要的操作，交互樣式是怎樣的，效果如何，最好單獨抽出來做成高保真，演示給他人看，讓他們對產品有深入的體驗和感受。

【2】數據顯示

原型上涉及的相關數據做好有真實的案例，將需要獲取的關鍵數據全部展示出來，比如一篇文章，需要的數據：作者、發布時間、瀏覽量、喜歡數、收藏數等，方便開發准備必要的數據介面。

【3】異常考慮

需要考慮一些突發情況的應對，比如斷網、載入太慢、數據已經被刪除了、數據找不到了、沒有訪問許可權等等情況。

【4】配套頁面

產品里的一些功能可能和其他產品有關聯，需要將可能涉及的其他頁麵包括到項目內。比如頁面在wap上手機的瀏覽樣式、一些發送給用戶的消息/簡訊的內容和樣式等等。

4.基本審美

【1】對齊

【2】間距

【3】顏色

【4】字體

推薦大家看看《寫給大家看的設計書》這類易上手的書籍。

5.基本規范

【1】頁面尺寸

       web的寬度有960px、1000px、1200px，App有安卓、iphone5、iphone6等，需要與已有的產品保持統一的尺寸。

【2】字體大小

     標題可以是18px或者16px，內容可以是14px。既要考慮用戶是否看到清，又要考慮美觀。

【3】顏色

     原型不要有太多的顏色，堅持黑白灰，除非要突出，可以用其他的顏色。

【4】彈窗

     彈唱的樣式最好做統一，彈窗名+內容+操作按鈕+關閉

【5】元件

   不在原型正文添加過多的截圖、圖標樣式，會對UI的設計造成干擾。

二.Axure的快捷使用技巧

       工欲善其事必先利其器，工具使用的越嫻熟，才能節省大量時間用於方案的思考。下面將簡要分享Axure繪制原型時的一些快捷操作：

      首先在頂部菜單欄中找到<視圖>，把需要的部件顯示，就可以設置了。

1.組件庫的建立（能提高效率，保證產品層面的統一一致）

2.母版的使用（適用於多頁面通用的部分，修改後，集體自動更新）

3.設置頁面樣式（頁面的字體、背景能一次性設置好）

4.元件的交互樣式

5.元件組合

       把要組合的原件用滑鼠框在一起，按住ctrl+G，成為組合後就可方便復制拖動了。許下按住ctrl+shift+G，也可以點擊選中後，點擊下圖的兩個圖標來組合和取消組合。

6.對齊、居中、平均分布

選中要對其的內容，選擇一種分布樣式，就能快速得到整齊的原型樣式，而不用一個個手動調整。

7.輸入框類型的設置（預設好類型）

一些輸入框，可能需要設置默認文字，可以直接選中了輸入框後，在原件屬性里設置提示文字和一些限制。

8.元件的提示語

        有些文字需要有滑鼠懸浮顯示提示語的動作，可以直接在原件的屬性里設置「原件提示」，輸入要顯示的內容，即可。

三、製作原型的過程

1.梳理功能點-------------------將需求轉化為功能清單，標出重要等級（前提是需求已經梳理清楚）

2.規劃產品結構----------------用Xmind或者筆和紙等工具畫出產品有幾個頁面，每個頁麵包含哪些元素

3.整理原型目錄----------------用Axure添加原型的幾個頁面，考慮頁面之間的跳轉關系

4.設計頁面的布局（打格子）-----用不同的色塊，方框來表示這部分將要表示什麼板塊，設計好頁面的布局

5.填充各模塊的細節----------在方框里把具體的信息和數據填充完整

6.增加少量的交互動作--------------體現在一些涉及到任務的操作

7.頁面注釋-------------完善交互說明

8.審查自檢------------------功能是否覆蓋完全；頁面有沒有缺失；流程是否明確；狀態是否完備

四、原型應用中的經驗

      因為我多是負責後台系統的優化，所以是直接和開發打交道，如果涉及前台頁面，就需要UI先將原型做成圖片，再由前端製作含有動效的demo，開發再按照demo開發。但是不論哪種，繪制出來的原型一定需要讓隊友都明白你的邏輯和要表達的重點。

      第一次負責項目的時候，我用的是高保真，畫完整的原型就花了一星期多，各種動作和交互，恨不得做個虛擬的產品。但是和開發講了原型後，等來驗收項目的時候，才發現，開發大部分都沒有按照原型上的動作來，甚至連細節都有遺漏。一個個催著補上後，我開始思考這種方式是不是不太劃算，太費事費力，結果又不太好。

       後來我看了我上級繪制的原型，都是以靜態頁面為主，可以說是低保真，但是每一種情況都詳細地用圖文描述清楚，點擊之後是什麼樣子，將要獲取什麼數據，失敗了會怎麼樣都有。而且這種方式，完成的特別快。於是我就選取低保真模式的開始畫原型，結果發現，開發有時候並不能將一些動作做好。

       於是我開始「T式原型 」。「T式原型 」就是大部分是以低保真鋪展開，將整個產品的邏輯都直接呈現出來，再在某些需要重點描述的地方用高保真描述深入。所以，我的原型大部分是以 低保真+注釋說明和高保真+動作演示 的組合。 不過對於交互簡單的產品來說，低保真模型足夠了 。

       每個產品繪制原型的習慣和風格都有所不同，但關鍵還是需要進行小組會議來向隊友們講解原型和邏輯，在開發的過程中，需要多溝通。

       另外，分享大家關於AXURE學習的網站，可以在裡面找到免費的軟體安裝包和教學課程。

https://www.axure.com.cn/

如果對文章感興趣，歡迎評論留言，堅持喜歡的事情，加油~

Ⅱ 產品經理的完整工作流程

初中級產品經理的完整工作流程

一、用戶調研

用戶調研分為定性分析和定量分析。定性分析是指用戶訪談，定量分析是指調查問卷。

用戶訪談。當然訪談需要一定的技巧，更多的傾聽為主，以了解用戶的內心想法為主。訪談時對用戶的初步回答反復追問「為什麼」，引導用戶從表面的行為開始思索，清理出行為背後的動機、需求乃至價值和文化觀念。

調查問卷。問卷調查是一項有目的的研究實踐活動，設計的問卷是為你的特定研究目的服務的，這是設計問卷之前必須植根於腦海中的一個觀念。既然問卷調查是一項有目的的研究實踐活動，那麼從理論指導實踐的角度出發，在設計問卷前必須要做好充足的理論准備，宏觀層面上應做到以下兩點：1.明確你們研究的主題是什麼 2.明確你們想通過問卷調查獲取的信息有那些。通過調研問卷你可以定量的驗證你提出的需求。

二、需求的收集，建立自己的需求池

收集各個部門的需求，建立自己的需求池。並定期對需求池進行整理。你的需求池裡面有不同人提出的需求。

定期對需求池做一定的梳理 。產品部門定期讀需求池進行整理，那些需求是下一步要做的，那些需求是是可以暫緩的，那些需求是不做的，對需求池進行梳理和分類。

不同終端的需求要分開 。分為APP、PC、微官網、前台、控台這些。

三、產品迭代前寫一份立項報告

通過對需求池的整理以後，你決定要做那些不做那些。需要出一份立項報告和技術部門過一下，這樣技術    可以安排開發周期。技術也可以從技術的角度給一些意見說那些可以做，那些可以暫時不做，這樣技術在開發之前有一個心理預期，這樣在你開原型評審會的時候阻力會小很多。這里教給大家一個小技巧：做立項報告的時候可以多寫一些需求，這樣多一些的需求可以給技術砍。

四、競品分析

俗話說知己知彼，百戰不殆。你做的東西別人也在做，買東西都還需要貨比三家呢。做競品分析有兩個目的，第一、揚長避短。吸引別人做的長處，發現別人做的不足的地方。第二、驗證與測試。別人上的這個功  能市場反饋怎麼樣，有沒有遇到啥問題，通過競品確定市場機會點。

競品分析有一定的流程。可以從「戰略層-范圍層-結構層-框架層-表現層」這幾個層面進行分析。

戰略層： 確定競品的商業模式、產品定位、市場狀況、盈利情況等，目的是確定方向，了解市場。

范圍層： 競品的目標人群，滿足了什麼需求，用戶的滿意度如何，目的是參考競品的目標人群以及需求的重要度。

結構層： 競品的主要功能架構、特色功能、發展模式，優缺點總結，目的是尋求差一點。

框架層： 競品主要任務流程的順暢，交互的細節，邏輯的准確，頁面的框架，目的是優化流程，提高用戶體驗。

表現層： 競品是視覺風格，顏色層級，文案的運用等，目的是維持用戶對這類產品的傳統認知的基礎上打造產品獨特性。

五、原型評審和PRD文檔製作

競品分析做完以後，開始根據競品分析的結果。開始自己的功能設計，流程的繪制，在原型上加一些功能的注釋，這樣在敏捷開發的時候可以節省PRD文檔的製作，也可以在和技術開會的時候不會遺漏自己想講的東西。

原型評審的時候技術人員的有效意見一定要虛心接受，不要覺得自己是產品就高高在上，涉及到原則問題堅持。別人提的有益意見也要虛心接受，只有這樣你才能避免死逼，項目才能盡快落地。至於PRD文檔的製作。有時間的話可以寫word文檔，沒時間的話可以直接在原型中製作文檔。但文檔必須包含的部分有：

1、產品版本的迭代歷史。 清晰的告訴項目成員每次改變都改了那些東西。

2、需求功能清單。 有需求功能清單 的時候技術人員在開發的時候才不會遺漏，測試工程師也會根據你的需求功能單來進行測試。

3、全局結構圖和重要的功能流程圖不能少。 產品全局結構圖相當於房子的骨架，相當於文章的目錄，別人看過你的全局結構圖就知道你的產品大概分成那幾個部分。其次，一些重要的功能流程圖需要 寫，這樣有助於開發人員思路的建立。

4 、異常流程要考慮清楚 。 只有異常流程考慮清楚產品經理才不會挨批，技術開發起來才不會出現問題。

5、重要名詞要定義。 對於首次出現的名詞需要定義，這有這樣別人在看到名字的時候才不會有疑問，再跑來找你問。

五、項目管理

項目進度表。 文檔交給技術開發以後，就需要制定一個項目時間表，並向領導匯報。首先要全面地收集他們在聽完需求文檔評審後對於產品本身的意見與建議，然後逐項予以合理的解釋，以保證程序員哥哥們打心底里認同這個產品，認同這個產品的每一個需求。另外作為一個PM，也應該要對基本的開發流程有所了解在制定每個需求的開發周期時提出正確的建議，保證最終的項目開發時間表既不會拖慢整個項目的進度，也沒有超出程序員哥哥們每天正常的工作量，保證他們不會感到過大的開發壓力。

進度跟蹤。 對於項目進度要做到心中有數，每天更新項目進度表，並幫助技術解決他們在開發過程中遇到的問題，並將自己看到的潛在問題盡量扼殺在萌芽中。當然，跟進並不是天天問工程師進度，需要給他們鼓勵打氣，並描述產品的未來前景，讓團隊中的每一個人都感受到自己的重任並願意承擔。可能有些團隊裡面是CTO擔任項目經理，這也無可厚非，畢竟在項目成員中程序員佔了大半資源，當然產品經理要盡量參與這個過程當中。不能當局外人。

六、產品上線前協助測試

大公司有明確的職位分工：工程師、測試、設計、運營都由不同的人負責，測試自然是測試工程師的事，而 在中小型創業公司，人員匱乏，很多團隊只有工程師和產品經理，工程師負責開發，開發以外的事情全都由產品經理承包，這 其中自然包括測試。但無論如何產品經理都要盡量參與測試工作，保證產品是按照你的預期做出來的。

1、首先與測試組溝通協作，確定產品測試排期。

2、跟進測試進度參與產品測試。

3、將測試出來的bug記錄下來，並拍好優先順序，反饋給技術來發人員

功能測試是合格產品經理的必備素質，產品經理要協助測試工程師完成測試報告並敦促工程師團隊改進產品。

七、產品培訓和推廣

給業務方培訓、推廣產品。 客服可能需要給用戶解答問題，所以每次迭代的內容都需要給客服培訓，好讓客服組織話術來應對客戶隨之而來的一些問題。同時也需要給市場、運營等部門培訓，讓他們知道產品到了那些階段，有那些改變，一是讓各個部門之間知道自己正在做的事情，二也好讓營銷市場部門做好宣傳與推廣。

收集產品使用反饋，為迭代做准備。 產品上線後設計的好不好，有哪些用戶滿意的，有那些用戶不滿意的。都會有用戶進行反饋，收集並分析這些用戶需求，並記錄在你的需求池裡面，為下一次迭代做准備。

八、數據分析

產品上線後產品設計的好壞很大程度上能從數據上體現出來。例如你設計個活動分享頁面，用戶可以通過好友分享的界面直接注冊，那麼你就要統計這個頁面的點擊量、PV/UV、頁面訪問市場、訪問深度、用戶的跳出率、用戶的轉化率等來評估你設計的好壞，以及活動的效果。再比如你產品進行改版，你需要評估改版的好壞。你就需要關注30日留存率提高了還是降低了，別關注7日留存率。因為你的產品剛更新你的粉絲用戶可能會很活躍，導致7日留存率變高，這個時候你說你的改版比較成功可能沒有說服力，也許30日以後你的用戶活躍度變低了，30日留存率也變低了。

九、總結

這就是初級產品經理的日常工作流程，每個公司可能根據自己的不同情況有些流程會有增減，但基本上是這些。

Ⅲ 原型評審要觀察哪些點

在原型評審時，要對產品的用戶體驗、功能的完備性、設計的一致性、界面的可讀性、用戶的接受度進行深入的評估，以確保最終交付的產品質量。

Ⅳ 產品經理是做什麼的

產品經理到底做什麼?簡單理解為：產品經理=策劃+執行

策劃=需求分析+產品方案

(1)一方面是進行需求分析

包括挖掘痛點，進行用戶研究，市場分析，數據分析，需求評估等一系列工作，通過這些工作搞清楚需求到底是什麼。

(2)另一方面是針對需求提出對應的產品解決方案

方案中包含產品的形態、產品的功能、實現策略、展示樣式等，一般一個需求可以通過多個產品方案來解決。但是只有一個可能是最合理的，比如：和朋友溝通的需求。

執行=文檔+評審會+項目管理+運營觀察

接下來我們說執行的部分，在執行部分有四塊重要的工作：

1. 把策劃部分確定的方案形成文檔，從而方便交流溝通

根據執行進度和溝通對象不同，主要包括商業需求文檔(BRD)、產品功能清單、流程圖、產品原型、產品需求文檔(PRD)等幾個文檔，這些是產品執行過程中非常重要的輸出物。

2. 進行執行過程中的各種溝通，主要是開評審會

在執行過程中，有大量的溝通工作，但是這些工作基本都是以評審會的方式進行，比如：需求評審會、UE評審會、UI評審會、測試用例評審會等，大家平台可能習慣私下溝通或一對一的溝通。但產品開發是個多部門協作的工作，涉及人員眾多，這種方式溝通效率太低，僅僅用做補充的溝通方式。

3. 項目管理，保證項目按時高質量的交付

主要做好以下4點基本上就可以了：

(1)開發排期

(2)跟進答疑

(3)異常處理

(4)產品驗收

4. 運營觀察，驗證假設並挖掘新的需求

產品上線是產品工作一個階段性的結果，整體產品目標的實現，還要靠後續的運營來實現。所以在產品上線後，並不是萬事大吉了，產品經理要對運營的過程進行觀察，包括用戶使用行為、習慣、數據等進行了解，尤其是對運營數據的收集分析，不僅可以從中去驗證自己的假設，而且也可以發現問題，作為下次迭代的需求的來源。

Ⅳ 產品經理主要工作流程是怎樣的

一、產品經理的需求來源

產品經理一切工作的本源是：需求。所以我們從需求來源開始講起產品經理完整的工作流程。互聯網需求來源一般有：

1、產品需求：產品經理通過數據分析、用戶調研、競品分析等方法驗證通過的需求

2、運營等業務部門提交的需求：比如以京東為例，服飾業務部/生鮮業務部/家電事業部的運營、采銷等人員出於提升業務指標的角度會提出各種需求

3、老闆的需求：領導從外部合作的角度或者產品戰略的角度也會給手下的產品經理提一些需求，比如我還接到過大Boss和老闆娘的需求

4、Bug修復等：在工作中修復BUG是一件比較常見的事情，影響面大的BUG會走緊急修復流程，不太嚴重的BUG會走迭代排期。

二、需求池的管理

通過以上幾種方法收集到的需求會統一放到需求池中。需求池大家可以理解為所有需求的集合（包含待確認、設計中、帶排期、開發中、已上線等所有狀態）。

一般來說，使用execl表格管理需求池即可，按照各種需求狀態進行分類展示。

三、需求優先順序

我們需求池的需求會非常多，但是每個迭代的時間是有限的/研發資源是有限的，所以導致我們只能從需求池中挑選出少量需求進行開發，從而誕生了需求優先順序的概念。

一個迭代中肯定有限做優先順序高的需求！

那如何排定需求優先順序呢？

一般來說有兩個場景：

1、從0到1設計一款產品

這種場景下的需求來源基本上都是產品需求。建議大家去了解一下KANO模型，這個場景下的需求優先順序一般來說是：基本型需求>期望型需求>興奮型需求

2、在原有產品基礎上優化

這種場景的需求來源會非常廣泛，可能之前講到的4中來源都是涉及，那如何排定需求優先順序呢？一般按照產品價值和實現成本兩個維度。

產品價值可以分為兩類：業務價值和用戶價值。

價值定義：

• 業務價值：對應商業類產品，稱為商業價值，體現在能給業務帶來多少收益。

• 用戶價值：對於使用者來說，能給他帶來的價值，比如說能減少操作步驟。

在這種方法下，優先順序的排序邏輯是：產品價值大實現成本低>產品價值大實現成本高>產品價值小實現成本低>產品價值小實現成本高。

四、需求確認

當梳理完需求優先順序之後，我們就按照開發工作量挑選優先順序高的功能組成新版本/新迭代周期的需求列表。

梳理完需求列表之後一般要跟直屬領導當面溝通一版，這叫需求確認。在這個階段要做好挨批、被懟的准備。領導會從各個維度「挑戰」你需求的合理性。所以大家在需求評審前一定要多思考幾遍，盡量多用客觀數據去說服領導。

如果需求確認通過，會進入到產品設計階段。

五、產品設計

產品設計階段會包含如下幾個小階段：

1、使用產品腦圖梳理產品/功能結構框架，特別是對一些邏輯復雜的新產品/新功能。

2、使用產品流程圖梳理產品/功能核心業務邏輯。流程圖的梳理盡量詳細，各種異常場景的判斷一定要在流程圖中有所體現。對於涉及多個參與方業務，可能還要梳理泳道圖。

3、使用墨刀/axure等原型工具輸出產品原型。原型是產品邏輯的可視化表現，也是產品經理最最基本的基本功。

4、撰寫產品說明文檔（PRD）。PRD是產品詳細邏輯的最終呈現，也是內部溝通的標准文檔。PRD撰寫完成之後就可以進入到需求評審階段

六、需求評審

需求評審是指產品經理要向UI、交互、研發、測試等內部人員講解產品邏輯，保證產品邏輯在內部傳輸過程中不失真。

需求評審的過程中，有4點需要注意：

1、評審的時候，先講需求背景。即這一版本為什麼要做這需求？做完以後預計會達到什麼效果？讓相關參與方從心理上認同做這件事的價值。

2、在講具體需求的時候，按照對應的責任人進行拆解。比如在講解功能A的實現邏輯時，我一般會說客戶端需要完成的內容是1、2、3；服務端需要完成的工作是1、2、3；演算法側的工作是1、2、3等等。

3、存在爭議的地方先記錄下來，評審結束後再細化。

4、就是評審結束以後要追排期。即作為產品經理你要盯著研發Leader，設計Leader，測試Leader讓他們出需求排期，以此保證項目按時上線。

七、項目管理

需求評審完成之後，項目經理（大部分公司由產品經理擔任）會輸出詳細的項目排期表，然後項目所有相關人員會按照項目排期表有條不紊的協作。項目管理的詳細流程如下：

八、數據分析

產品上線之後，產品經理要做好產品分析工作，以驗證產品/功能是否達到預期目標。特別是產品上線7天後，產品經理需要想全體組員發送產品上線數據報告。

如果數據不達預期，就要進行深入的分析內在原因是什麼，然後數據分析的結論很可能是下一迭代的需求來源，從而開始一個新的迭代周期

Ⅵ 產品經理的相關說明

用心：對自己對產品負責任
同理心：從用戶角度出發
處處留心
沒心沒肺：臉皮要厚，不要怕人罵 同程序員不一樣，產品經理主要是同人打交道，要組織處理好很多復雜的關系和工作。良好的溝通能力、組織協調能力、資源運用能力、推動和協調各部門的合作和有序進展，是一個產品經理需要具備的綜合能力。所以做好產品經理並不是一件容易的事情，很多方面的素質培養是必不可少的。
產品經理要協調好各種關系，包括研發、測試、文檔、市場、銷售等部門的人，在保證品質的情況下如期的推出產品。任何事情都是靠人實現的，所要協調的主要是人力資源，絕不能因為要完成一個OEM的項目而佔用所有測試人員的時間。不同部門的溝通並沒有多大的區別，但不同部門的Leader做事方式可能不一樣，因此一方面要看對方配合的程度高低，同時要學會在恰當的時候和恰當的人談恰當的問題，只有解決好問題才能有效的將事情向前推進。尤其是在沒有下屬關系的情況下，人與人的互動上，要做的非常好，能夠把自己的想法非常好的表達給其他人，說服這些人配合去做事。
產品經理的工作是相當瑣碎的，要處理各種各樣的關系和進度，不像其他的工作都有自己專注的方向，專業的領域。所以如何在一天之內高效的做事就顯得尤為重要。
圍繞目標市場、市場調查、市場定位、市場細分，通盤考慮產品、價格、渠道、促銷、公關、服務這些因素是開展營銷工作也是產品管理的一項很重要的工作。所謂市場感覺，更為重要的是如何能夠通過市場現象去生成一些戰略，而不是對方降價自己也降價，對方做廣告自己就做廣告。所謂戰略，就是從產品定位、用戶定位、價格和競爭對手入手，了解各自的強項和弱項，找到機會在哪裡，威脅在哪裡，並進行分析，制訂未來的戰略。這些素質不是通過看市場宣傳和匯報就能夠獲得的，它需要很多的信息反饋分析，要靠經驗和感覺。
作為一個產品的負責人，產品經理的壓力是很大的。盡管在某些公司，產品的成敗不一定和產品經理的收益掛鉤，但如果某些方面考慮不周，做出來的母盤存在問題，造成整批產品銷毀，給公司帶來巨大損失，或者因為某些原因沒有和一些人員溝通好或者安排好時間，結果造成問題，產品無法如期交付，產品經理還是有「罪魁禍首」的感覺，這些都是壓力所在。
產品經理需要有獨立解決問題的能力和動力，要把產品看做自己的孩子，懷著熱情和激情去做事。這種熱情決定他是主動的，而不是被動的去做事，是為了不斷提升自己的價值和能力。
技術可以學習，素質卻難以培養，有些素質是成功的產品經理必不可少的。
有這樣一群人，他們對產品有一種本能的熱愛，把自己生活中的一切事物都看成產品，懷揣對優秀的產品的熱愛和尊重。這份熱情是產品經理必備的素質，是他們夜以繼日克服困難、完善產品的動力。這份熱情能感染團隊成員，激勵所有人。
辨別這種特質很容易，可以讓應聘者談談自己最喜歡的產品及喜歡的原因，聊聊不同領域的產品和他討厭的產品，問問對方，如果有機會，他打算怎樣完善自己最喜歡的產品。熱情是難以偽裝的，虛偽的做作容易畢露無遺。
理想的產品經理不一定來自產品的目標市場（這種情況有利也有弊），但是他必須融入目標市場。這一特質對製造大眾產品的高科技企業尤為難得。我們傾向於從自己的角度去理解用戶和市場。事實上，目標用戶的經驗、喜好、價值觀、知覺能力、忍受程度、技術理解很可能與我們的大相徑庭。
可以就產品的目標市場向應聘者發問，讓他談談如何換位思考。了解應聘者對目標市場的感覺，最重要的是看對方是尊重目標市場希望融入其中，還是打算一意孤行改變用戶習慣。
對國際化的產品和針對特定地域的產品來說，換位思考尤其重要。各種文化雖有共通之處，但也存在許多差異。有些差異對產品無關緊要，有些則至關重要。應該考察應聘者是否足夠了解目標市場，能否區分這兩種差異。
人的智力水平是無法替換的。產品管理需要洞察力和判斷力，因此必須具備敏銳的頭腦。勤奮當然是必需的，但從事這項工作光有勤奮還遠遠不夠。
招聘聰明人是項知易行難的任務，結果在很大程度上取決於招聘者的能力和可靠性。常言道，「物以類聚，人以群分」，此言不虛。方法之一是測試應聘者解決問題的能力。微軟令人稱道的、深入而有效的面試，即是考察應聘者解決問題的能力，通常由一位或多位領域專家就一個問題對應聘者進行深入考察。面試官不關心應聘者是否知道正確答案，而看重應聘者解決問題的思路和方法（智力優於知識）。如果應聘者回答正確，面試官會將問題略作調整，詢問應聘者在新情況下如何應付。重復這個過程，直到應聘者被迫處理他不知道答案的情況，說出解決方法。
每種團隊角色承擔的義務和付出的努力都不相同。產品經理肩負著產品的前途和命運，絕不適合貪圖安逸的人擔任。即便掌握了時間管理和產品管理的技巧，產品經理依然要為產品投入大量精力。成功的產品經理能擁有時間享受清閑的家庭生活嗎？只要具備足夠的經驗，我相信可以做到。但是，如果你期望的是一周只工作四十個小時，下班後把工作拋諸腦後，那是不現實的。
成功的產品經理需要付出多少努力？在這個問題上，我對應聘者向來坦率，產品管理工作絕不能用時間來衡量，付出多少都不為過。緊急情況下臨時找來的「救火隊員」多半不是合適的產品經理人選。
在漫長的項目周期里，產品經理需要付出的努力和承擔的義務並非一成不變。有的階段比較輕松，有的階段則很緊張。但是稱職的產品經理對產品的關注和憂慮程度，以及願意為之付出努力的熱情是不會改變的。
在所有產品團隊成員里，產品經理最能體現公司和產品的價值觀。通常產品經理不直接管理團隊成員，不能要求別人執行命令，所以他必須通過行動影響、說服身邊的同事。這種影響基於相互的信任和尊重，要求產品經理必須是個正直的人。
產品經理是產品團隊、銷售團隊、公司高管之間的樞紐，經常要協調處理各種問題，比如提早供貨、滿足大客戶的特殊要求。產品經理如何處理這些難題，同事們都看在眼裡。
信任和尊重需要時間培養，產品經理唯有通過工作展示自己的素質和能力，才能成為真正的團隊領導。如果產品經理對待同事缺乏誠意，懷有私心，一碗水端不平，那麼勢必會影響整體團結的工作效率。產品經理雖然不必事事精通，但應當知道每位成員最擅長做什麼，尊重大家發揮工作特長的意願，充分信任大家。
考察一個人是否正直絕不比考察他的智力容易，考察陌生的應聘者是否正直就更難了。對那些有工作經驗的應聘者，可以問問他們如何處理工作中的壓力，多追問工作細節。
很多人相信經驗可以讓人產生自信。如果僅憑經驗可以建立信心，為什麼許多工作多年的產品經理卻毫無自信？相反，剛剛步入社會的大學畢業生卻往往充滿自信（雖然這種自信通常源自對自身狀況的無知）。
自信是很重要的素質。公司高管、產品團隊、銷售團隊都需要看到產品經理的信心，確信他們投入的時間、金錢、努力不會付之東流。自信的人更有說服力，更容易成為人們願意追隨的領導者。
稱職的產品經理把自己當成產品的CEO，願意為產品的最終成敗承擔全部責任，絕不找借口。雖然他清楚產品按時成功上市要克服許多困難——開發難度大、開發時間長、成本過高、產品復雜等，但他明白預見和解決這些問題是他的責任。
這並不是說產品經理要事必恭親，監督每個人的工作，而是指出現問題時他應該及時承擔責任，進展順利時他應該及時給大家以鼓勵。稱職的產品經理知道，雖然產品的實現離不開大家的協助，但是他應該對自己的產品創意負責。
掌握一些重要的技能是打造成功產品的關鍵。我相信，只要具備優秀的個人素質，所有技能都可以習得。
很多成功的產品經理是工程師出身，因為策劃產品在很大程度上取決於對新技術的理解，以及如何應用技術解決相關的問題。
出色的產品經理並不需要自己發明或實現新技術，但必須有能力理解技術、發掘技術的應用潛力。
培養理解技術的能力有多種途徑，可以參加培訓課程，閱讀相關書籍和文章，向程序員和架構師請教，參加開發團隊的頭腦風暴也不失為一種途徑。
產品經理要優先解決重要問題。研發產品的過程中有很多干擾。能否集中注意力解決關鍵問題、剋制不斷增加功能的沖動、不受關鍵人物或重要客戶的影響，取決於產品經理是否有足夠強的自律性——不但要遵守公司制度，還要嚴格要求自己。
幾乎所有產品都有些不那麼重要的功能——這些功能對提高銷量和用戶滿意度毫無作用。如果去掉這些功能，產品甚至會因為簡單、易用獲得更多用戶的喜愛。
電子郵件、即時消息和手機構成的世界充滿了干擾。你可能一大早就來上班，拚命工作一整天，連吃飯喝水都顧不上，深夜回到家卻發現到頭來沒完成一件重要工作。時間都用來「救火」和處理「緊急」事件了。
熟練、迅速地區分重要任務和緊急任務，合理地規劃和安排時間是產品經理必備的技能。如果產品經理無法集中精力完成真正重要的任務，那產品就難免命運多舛了。
每星期工作七十個小時、累得精疲力竭的產品經理。他們把所有的時間和精力都花在工作上，體力透支到了極限。對他們而言，最可怕的事實莫過於做的都是無用功。為此，我有意在培訓課程中加入了時間管理和合理安排工作任務的內容。產品經理的時間應該用來改變現狀，而不是疲於奔命參加大小會議、逐一回復郵件。有許多事情不值得做。
作為產品團隊的發言人，產品經理要協調團隊與財務部門、營銷部門、銷售團隊、公司高管之間的工作——必須使用這些人聽得懂的概念和術語。
我認為產品經理應該具備雙語技能。這並非指中文和英文，而是指產品經理既能與程序員討論技術，又能與管理層和營銷人員討論成本結構、邊際效應、市場份額、產品定位和品牌。 教育培訓
產品經理是要負責產品的整個生命周期的所有事物，因此產品經理需要有產品研發階段相關的技術知識。在軟體開發領域，產品經理一般是研發出身，接受過市場營銷相關培訓。
工作經驗
產品開發及其管理5年以上工作經驗，具備良好的資源整合能力、溝通協調能力和書面報告能力，具備獨立解決問題的能力和較強的市場分析能力，對產品和數據運營敏感，思維清晰而有條理，能承受較大的工作壓力。 對於大公司而言，產品經理是一個非常重要的角色。因為產品經理要負責整個產品的成敗，所以從研發到生產到銷售，產品經理都有權進行干涉。但是在小公司境遇就不盡相同，權力會相對小一些，但是產品經理對於提高自己的創新能力，選擇創業是非常有幫助的。產品經理一般由產品專員發展而來。
在戰略層面需要考慮的內容
在產品規劃和執行層面
產品開發團隊管理
產品實施和推廣
因為不同公司對產品經理/產品設計師的職責要求不同，所做的事情也並不相同。但至少要達到所在公司的要求，這才是首先應該做的事情。 原型製作：Axure，Mockplus,fireworks，Photoshop，mockingbird（web）,Balsamiq Mockups,omnigraffle等，區別去其他的原型工具，Mockplus兼具審閱功能，更加方便了設計，提高了工作效率。
項目管理：PriciseProjectManagement（PPM），Project（微軟產品），Todolist，Excel，Sheet，Gcalendar，Google task，trac，outlook
在線協作：SVN，Google Docs,Mockplus
測試反饋：TestCenter，QC,Jira,Bugzilla，Firebug、TestDirector、IETester
需求池管理：Mantis
團隊交流：QQ，outlook，MSN，GTalk，畫聲（精準溝通）
工具推薦：多用下載
筆記軟體：Evernote（印象筆記），Onenote（微軟產品），麥庫，有道雲筆記，為知，輕筆記
代碼編輯：Editplus，UltraEdit，Sublime Text 3，Textmate，Notepad

Ⅶ 產品經理日常：剛接到一個新需求，應該怎麼處理

作為產品經理，接收需求簡直是我們日常工作中再基本不過的事情了，只要和你有交集，都有可能產生需求，有可能是用戶直接反饋的需求，也有可能是公司運營、市場等部門同事給你反饋的需求，也有可能是老闆直接給你提的需求，當遇到這些需求的時候，我們應該怎麼去做呢？

我們首先需要去判斷下這個需求的真偽，接下來根據我們分析需求的優先順序進行排序，讓我們的產品圍繞核心目標朝著一個健康的方向不斷進行迭代。中間最關鍵一點就是要做好溝通反饋，不然給你反饋需求的人會認為你沒有重視起來，對於需求方來說會產生很多負面情緒，所以這一點一定要重視起來。

接下來，我們再來聊聊怎麼去分析需求，或者說怎麼去判斷需求的真偽，我們知道在設計某個功能的時候，就是為了解決用戶在某個場景下所發生的需求，從而解決這些問題，這個功能才會存在價值。那麼，如果用戶提的需求我們理解的不正確，設計的功能很可能無法真正解決問題，甚至僅僅是解決了用戶的表面需求，出現功能做了，用戶也不會去用，導致我們時間和精力都浪費了，最後的結果也不太令人滿意。

那麼，當我們遇到需求的時候，是否應該立即去處理呢？

我建議應該這樣去做：

1. 用戶為什麼會產生這個需求？

當需求方向你闡述完某個需求後，向他詢問：提這個需求的目的是什麼？即為什麼會產生這個需求？這個問題可以幫你完全理解需求，並辨別需求的真偽。

2. 用戶在什麼場景下會使用這個需求？

即搞清楚什麼人在什麼情況下會用到此功能。明白了這個，才知道如何更好地設計功能來滿足需求。

3. 是否有可能衍生出新的場景？

為了避免設計的功能因擴展性不足，後期推翻重來，在一開始，就應該做盡可能全面的考慮。通過需求方的場景，擴展思考，是否存在衍生的場景。思考的過程，也是幫助你抓住和理解需求本質的過程。

4. 技術層面如何看待這個需求？

接到需求，並充分理解了需求後，跟相關技術負責人花幾分鍾時間討論一下，聽聽他從技術上對需求的考慮。通過此過程，你們基本會對需求點及實現方式達成共識，在後期正式開發時，阻礙會小得多。

5.做了這個需求對用戶有什麼影響，以及用戶對這個需求的緊急和重要程度是怎麼樣的？

一定要問清楚，處理這個需求對用戶的有利影響和不利影響是什麼，從而判斷需求的類型，以及緊急重要程度，最後一定要多詢問一句，需求方對這個需求的緊急重要程度的認知，避免我們分析完需求的緊急重要程度和需求方理解的不一致，導致最後出現矛盾。

那麼，當需求方對需求不明確的時候，應該怎麼處理呢？

我建議這樣處理：

1.最直接的方式，誰提出的需求，找誰搞清楚需求，最好讓需求方把場景描述清楚，還原需求的真實使用場景，有助於幫助我們來更好的理解需求，有可能需求方調研清楚以後，該需求可能就不會存在了。

2.如果需求方也說不清楚自己想要的是啥，在你聽完他不清晰的描述後，利用你的專業技能，幫他梳理，並跟他確認，你的想法是否正確，是否就是他想要的

3.向對方提問題是搞清楚一件事情最好的方式，或許可以嘗試這么問需求提出者：什麼人在什麼情況下會做什麼事？你現在實際操作中覺得哪裡是最困難不方便的？你覺得最好的操作方式應該是什麼樣的？類似這類問題，既是幫你搞清楚問題，也是幫對方梳理思路。

當需求明確後，後續的工作流程就會清晰很多，我們做個復盤，來看下我的工作流程：

第一步 ，與需求方進行溝通，主要是復述你接收到的需求，確保需求接收正確沒有存在理解偏差。

第二步 ，我把它叫做清洗需求池，把接收到的需求進行清洗，分類出那些是已有替代功能完成了的，哪些是在之後的版本中有規劃的了，哪些是與公司戰略及產品目標不符合的需求，哪些是可以在這個版本加入的需求，同時評估需求的可行性、優先順序、難易度。

第三步 ，將上述第二步的結果形成文檔，並提交需求方，最好是自己親自講解，獲取需求方的同意。這一步至關重要。

第四步 ，需求的具體分析，梳理邏輯關系，業務流程。

第五步 ，進行原型設計，如果需要出PRD，再這個階段也一塊進行輸出。

第六步 ，開原型評審會（就是我們常說的kick-off會議），與UI、研發一同溝通需求及PRD，對會上的東西進行及時的補充和改進。

第七步 ，跟進UI設計稿，確認設計稿。

第八步 ，協助研發開發，開始編輯測試用例和測試文檔，並准備種子數據（如果有測試，就協助測試完成，如果沒有，就自行完成）

第九步 ，測試，驗收產品

第十步 ，上線，交付產品

以上流程中有的階段可能會反復進行，最為重要的就是我們的溝通能力，下期我們繼續講解如何提高溝通協作能力，最後還是希望大家持續關注，微信公眾號中搜索「小寶談產品」，讓我們一起在產品和運營的路上不斷前行～

Ⅷ 我想當一名產品經理，應該如何入行

深圳某互聯網公司產品經理，也是從小白做起，對著話題感觸頗深。

首先，你要明白產品經理的也是分責任范圍的，選品討論，競品報告，設計開發，溝通協作。包含很多硬實力和軟實力，不了解的可以看看這篇回答。

那在這里，我就選擇其中一個我覺得難一些的模塊,給大家進行分析。關於怎樣開發一款APP。

對於產品經理來說，app的模板肯定是由技術人員打造，我們就是與甲方協商寫出合理的要求，並規劃其未來發展。

第一步，就需要我們觀察市場，評估市場，初步給出合理·業務方案。 關於需求調研的方法，這篇寫得很細，有需要的自己去學習

第二步就是與原型評審溝通，製作產品原型圖，我建議用思維導圖去梳理，這樣效率會更高。

第三部就是原型定版後，編寫PRO文檔和繪制流程圖，與程序架構師溝通代碼和資料庫框架，與UI深度溝通產品視覺主題風格。

最後一步就是整體測試，進行線上試運營。

當然每一步針對不同的APP都有不同的辦法，看起來文字很簡單，但實際操作起來是有難度的。 對於成熟的產品經理來說，你也是個最基礎的程序員和UI。因為你有這兩項的基礎，你才能跟專業人員進行合理溝通。

但很遺憾是小白入職時基本上是不懂這些的，所以如果你能學會你的籌碼會更大些。我們公司在進行員工內訓一般都會用PUMP家的課程，分析的很精簡，一周左右就會有效果，畢竟企業不會等你成長。

暫時就說到這里了，祝大家都能找到心儀工作。

Ⅸ 產品經理是做什麼的

產品經理是貫穿產品整個生命周期的重要角色，從設計、開發到後期的維護推廣都離不開產品經理的串聯溝通。

1. 客戶溝通：產品立項階段需要確立客戶群體，與潛在客戶溝通。

2. 需求分析：立項以後做競品分析，客戶需求梳理等工作，確立產品的需求范圍和功能特點。

3. 產品設計：協助設計人員做產品設計工作，對產品原型進行評審與分析。如果需要，還要拿產品原型與客戶溝通，修正產品的需求。設計完成需要與開發人員討論方案可行性與成本等問題。

4. 開發進度管控：跟蹤產品開發進度，保證產品開發按計劃執行！

5. 產品測試

6. 產品發布與升級
   

Ⅹ 產品經理必備技能 | 如何畫原型

產品經理當然要會畫原型啦~

聊聊怎麼畫原型吧！

在畫原型之前，更重要的事情，就是畫 頁面流程圖 和 信息架構圖 ！假如你沒有這些東西，就開始畫原型，那麼等著你的就是沒完沒了的改改改。

頁面流程圖是以用戶視角，看流程合理性。通常適合於跳轉比較復雜的產品功能，如電商、社交產品。

為什麼要畫頁面流程：

（1）是交互設計/原型設計的基本依據，是邏輯基礎。如果你都沒想好頁面流轉的順序，那麼你畫的原型一定不是可以確定下來的版本

（2）代表了用戶的操作過程，先畫頁面流程圖能迅速發現體驗問題。有了頁面流程圖，你可以設身處地想像用戶在使用產品時的操作流程，發現其中可能出現的問題

（3）突出頁面重點元素與邏輯關系，提升原型的設計效率。很多頁面不是全新頁面，而是在原有頁面做一些修改，如果你知道頁面流轉順序，那麼會給你畫原型減輕很多工作量

頁面流程圖包含：

（1）四方形：業務流程中的四方形部分，異常流程或彈層通常用菱形表示

（2）流向：主幹流向和輔助流向

（3）重點元素：每個流程中，重點要體現和表達的內容是什麼

畫頁面流程圖的工具：

（1）Axure：畫了頁面流程圖可以緊接著畫原型

（2）ppt：方便講解

需要注意的地方：

（1）回歸業務流程，明確主線：頁面流程一定來自於業務流程，一般為業務流程中的方形部分。異常流程一般為彈層或彈窗提示。業務流程畫的好，頁面流程就簡單。

（2）明確頁面中的重點元素：功能在頁面中，有哪些是需要表現元素。增加異常流程的處理邏輯。增加輔助的幫助頁面。考慮下游觸發點（按鈕/鏈接/滑動...)。

（3）溝通與優化：首先要盡可能窮舉涉及的頁面，然後做減法，有些頁面合並或刪除。通過原型草圖，優化調整頁面關鍵元素。與UI、UE、前端研發多溝通會有更好的效果。

頁面流程圖一般規則：

頁面流程圖例：

一個具體案例：

業務流程：

頁面流程：

主要是分離出了普通用戶的操作流程，加異常處理。

對於普通用戶的關鍵頁面和關鍵流向：

頁面流程圖：

（1）分離出5個頁面，確定流程流向

（2）固定元素，例如在「1購物車」中，「提交訂單」就是下游觸發點，點擊後流向下一個頁面；在「2輸入優惠碼」中有關鍵元素「填寫優惠碼」，另外還有下游觸發點「確認訂單」...

（3）針對每個頁面去畫對應的原型圖

信息架構圖，以產品視角，看包含多少功能點。適合於層級分明的，如音樂產品、新聞客戶端、閱讀類產品等。

信息架構圖例1：

有了頁面流程圖或信息架構圖，現在終於可以開始畫原型啦。首先，什麼是產品原型設計？

產品原型 ，俗稱 線框圖 ，大概就是草圖的意思吧。它是產品落地的關鍵點，是從虛擬概念到用戶接觸的節點。同時也是產品經理產出的關鍵內容，上傳下達，上給老闆，下給UI、UE同事。

產品從原型到上線的流程：

大公司的產品經理只需要做手繪和低保真的部分，小公司可能還要兼職交互設計...

案例：

好的原型有什麼特點：

（1）整體：頁面結構清晰、跳轉關系明確、與業務流程一致、完整表達用戶需求

（2）獨立頁面：功能元素明確有序、位置關系清晰、不同狀態變化清晰

（3）交互設計：清晰的交互邏輯、一致交互方式、界面統一

常用工具：

（1）紙筆：自己畫畫，快速學習和定位

（2）白板：多人討論

（3）軟體Axure/Sketch/墨刀：產出正式文檔

案例：

（1）研究流程：業務流程->頁面流程

（2）確定頁面框架：大概確定頁面布局和大的框架

（3）畫原型：畫模塊，確定交互細節

注意事項：

（1）盡可能用真實比例、真實文案，使元素更真實，也避免在需求評審時被之一。盡可能真實模擬極端情況，並示例清楚。
（2）緊扣需求主體，不橫生枝節。如果原型需要增加新功能，一定要是來源於需求，並且要考慮後端數據來源。

（3）不要上顏色！原型就用黑白灰，不要給UI、UE挖坑

（4）目錄樹清晰，閱讀流暢

（5）保存修改記錄，關鍵修改重新保存文件

畫/改原型的時間盡量控制在20%工作時間之內，否則就要問問自己是不是哪裡出問題了哦。

產品需求想明白了沒？？？

產品流程理清楚了沒？？？

手繪草圖畫了沒？？？

手繪草圖和Boss確認了沒？？？