產(chǎn)品開發(fā)流程。

產(chǎn)品研發(fā)產(chǎn)物。

主要分為五個階段：項目啟動,需求階段,產(chǎn)品設(shè)計,開發(fā)上線,版本迭代。

立項 啟動 評估立項：確定要做一個什么產(chǎn)品。

啟動：確定項目相關(guān)人員,項目需求,產(chǎn)品原則,時間排期。

評估：評估產(chǎn)品機會。

需求階段需求收集來源：老板提出,項目需求,產(chǎn)品優(yōu)化,業(yè)務(wù)需求,用戶需求,運營需求,增長需求,商業(yè)化需求等。

方式：頭腦風暴、用戶調(diào)研、用戶反饋、競品分析和數(shù)據(jù)分析。

頭腦風暴產(chǎn)品、運營、視覺、技術(shù)都可以參與。

人數(shù)不要過多,超過5個效果反而不好。

圍繞著一個核心問題,自由發(fā)揮發(fā)表觀點,不評論對錯。

產(chǎn)品要做好會議控制,避免漫無邊際的討論,同時做一個好的timer。

如果氛圍尷尬,可以嘗試引導(dǎo)做問題拆解,將一個點,解析成幾個關(guān)鍵點討論。

或拋出設(shè)想和問題。

注：一定要有人做記錄,可考慮錄音。

用戶調(diào)研方式：問卷調(diào)查、用戶訪談、可用性測試。

注意：多聆聽、觀察和思考。

注：可用性測試需要專業(yè)的觀察室,往往只有大廠會做,也往往是交由用戶研究員來完成。

一般是已經(jīng)開發(fā)完成某項功能,讓一群有代表性的用戶對產(chǎn)品進行操作。

觀察員在旁邊或者監(jiān)控設(shè)備中觀察和記錄。

目的是發(fā)現(xiàn)用戶真實使用過程中,會遇到的問題,用以提升產(chǎn)品可用性。

用戶反饋用戶反饋可以跟用戶增長結(jié)合在一起做。

定個策略,比如使用多少時長后,或者完成某項任務(wù)后,彈出一個邀請評分窗。

用戶要是選擇四星或以下,點OK鍵,則進入反饋流程。

如果是五星則引導(dǎo)去應(yīng)用商店評分。

這種做法巧妙在于,不僅可以很有效的過濾掉負面評價,讓負面評價留在反饋系統(tǒng),而且還能讓應(yīng)用商店的好評獲得大幅增長。

市場分析考察大環(huán)境的情況。

分析法——PEST和SWOTPESTPEST 是一種宏觀環(huán)境分析模型,所謂PEST,即 Political（政治）, Economic（經(jīng)濟）, Social（社會） and Technological（科技）,從四個維度分析大環(huán)境。

SWOTSWOT即S（strengths）是優(yōu)勢、W（weaknesses）是劣勢,O（opportunities）是機會、T（threats）是威脅。

清晰地把握全局,分析自己在資源方面的優(yōu)勢與劣勢,把握環(huán)境提供的機會,防范可能存在的風險與威脅。

這是SWOT分析法的目標所在。

競品分析前期可以做比較全面的競品對標,橫向的縱向的跟競品進行對比。

對比產(chǎn)品之間的優(yōu)劣勢,比如資源、渠道、技術(shù)等。

對比目標戰(zhàn)略方向、用戶選擇、產(chǎn)品策略。

對比產(chǎn)品功能點。

對比競品是如何做用戶體驗,怎么處理邏輯、界面層級和細節(jié)的。

等等。

如果是一個新來者,還可以查看對手的迭代記錄,從而繪制出對手的迭代圖譜。

競品分析其實很重要的在于競品追蹤。

時常留意競品做了哪些迭代。

你要對這些迭代做思考,思考迭代背后的動機是怎樣的,可能會產(chǎn)生哪些效果,這些迭代功能是否要跟進。

除了通過看對方用戶反饋和情報了解外,有時候確實還是不好判斷效果如何,因為數(shù)據(jù)畢竟是掌握在對方。

這時候可以看看對方接下來做出的調(diào)整和修改,用來佐證判斷。

當然這種方式周期很長,你也可以嘗試做AB測試。

數(shù)據(jù)分析要從根源解決問題才行。

所以拆解問題很重要,找到問題存在的所有可能性。

再尋求統(tǒng)一的解決方案。

對問題進行拆解或者歸因,再反向?qū)で蠼鉀Q方案。

這時候就需要從業(yè)務(wù)邏輯出發(fā),腦海中去模擬使用場景。

理清脈絡(luò),順藤摸瓜。

再結(jié)合數(shù)據(jù)看,就能比較容易發(fā)現(xiàn)問題。

除自身數(shù)據(jù)外,還可以參考一些數(shù)據(jù)調(diào)研機構(gòu)的分析報告,比如艾瑞資訊等對互聯(lián)網(wǎng)行業(yè)做的數(shù)據(jù)分析。

還可以試試百度指數(shù),淘寶指數(shù)等工具。

海外市場的分析工具：。

Appsflyer /Adjust:用戶獲取渠道分析歸因分類平臺,方便統(tǒng)計不同渠道給同一谷歌商店上架產(chǎn)品的貢獻數(shù)量和轉(zhuǎn)化效率。

Appannie :不同國家APP市場的行業(yè)數(shù)據(jù)分析、競品數(shù)據(jù)分析等。

Google analytics :產(chǎn)品內(nèi)部數(shù)據(jù)檢測分析、渠道分析等盈利分析盈利模式指按照利益相關(guān)者劃分的企業(yè)的收入結(jié)構(gòu)、成本結(jié)構(gòu)以及相應(yīng)的目標利潤。

通俗來說,盈利模式就是企業(yè)賺錢的渠道。

有效的盈利模式分析有利于企業(yè)從既有的單一賺取利潤的思維定式中解脫出來,尋求更為多元的利潤來源方案。

那么互聯(lián)網(wǎng)產(chǎn)品在進行盈利模式設(shè)計時首要考慮的是什么呢？是用戶。

互聯(lián)網(wǎng)產(chǎn)品盈利模式設(shè)計的首要原則就是“以用戶為導(dǎo)向,以利潤為中心”。

而定義一個好產(chǎn)品的基本要求就是“滿足用戶的需求,完成企業(yè)的指標”。

互聯(lián)網(wǎng)產(chǎn)品盈利模式設(shè)計應(yīng)以用戶價值為核心,并需要在市場細分和客戶偏好分析的基礎(chǔ)上,通過有效的定位來抓住高利潤的客戶群,實現(xiàn)穩(wěn)定盈利。

互聯(lián)網(wǎng)產(chǎn)品盈利模式思維導(dǎo)圖互聯(lián)網(wǎng)產(chǎn)品盈利模式思維導(dǎo)圖。

需求分析&篩選篩掉明顯不合理的需求這個階段的判斷標準就是需求的合理性,用你的經(jīng)驗、專業(yè)知識,甚至是直覺,過濾掉大部分需求。

比如,當前技術(shù)不可能實現(xiàn)的或意義不大的、投入產(chǎn)出比低的、明顯不合理的需求。

因為從各種不同渠道會收集到大量的需求,為了提高效率,你不得不這么做。

當用戶量達到一定規(guī)模后,光每天收到的用戶反饋就夠你喝一壺的。

甚至因此,你不得不做一個用戶幫助和反饋系統(tǒng),來幫助你過濾和初步加工需求。

有個簡單的判斷方法：這需求做了會怎樣？不做又會怎樣？。

如果做不做沒多大區(qū)別,甚至做了會起到負效果,那就不需要猶豫了,可以直接過濾掉這條需求。

挖掘用戶的潛在需求和動機這是用戶需求進化為產(chǎn)品需求的關(guān)鍵一步。

用戶需求：need,用戶想要的。

產(chǎn)品需求：solution,解決方案。

可以是推薦算法優(yōu)化、界面布局調(diào)整、新功能點,甚至是新產(chǎn)品等等。

以上是用戶需求和產(chǎn)品需求的定義,用戶需求是用戶想要的東西,產(chǎn)品需求是滿足用戶需求的解決方案。

用戶畢竟不是專業(yè)人士,考慮問題的出發(fā)點是用戶自身,這就需求產(chǎn)品經(jīng)理去挖掘用戶的潛在需求和動機。

最著名的例子就是：If I had to ask customers what they want,they will tell me:a faster horse.“如果我當年去問顧客他們想要什么,他們肯定會告訴我：一匹更快的馬.’”。

如果福特先生不去挖掘用戶背后動機的話,可能就去研究馬的配種問題了,而不會有福特汽車了。

那么如何挖掘用戶潛在需求和動機？用戶需求的產(chǎn)生,帶有很強的不確定性,受環(huán)境、情緒等各種因素影響。

所以光看表面描述不行,得有代入感的去感受。

可以通過以下幾個要素進行場景分析：。

用戶需求=誰（用戶特征）+在什么情況下+想滿足什么？。

比如你是Todo list產(chǎn)品經(jīng)理,調(diào)研過程中,某用戶反饋添加過程太麻煩了,沒法批量添加。

追問為什么需要批量添加后,對方回答,她是一名學生,想要把課程表導(dǎo)入到list中,方便查看。

這時候你就明白了,對方是一名大學生,在添加操作的環(huán)節(jié)遇到了麻煩,她是想要添加課程表。

這時候你就可以馬上找到解決方法：可以利用OCR技術(shù),只需掃描一下,直接將整張課程表導(dǎo)入進來。

再深入思考一下！添加課程表就是最終的目的嗎？ 顯然不是,對方添加課程表后,一是為了方便查看,二是為了上課時間快到時提醒她上課。

那么就可在導(dǎo)入后,行程一個可視化的日程表,提前提醒上課。

這就是需求挖掘過程。

需求歸類整理挖掘到用戶的真實目的后,會發(fā)現(xiàn),多個看似不同的需求背后,原來是出于同一個目的。

這就可以將這幾個需求歸納為同一個。

接著可以通過如下維度歸類整理需求：。

1）判斷是否有價值：廣度、頻率、強度。

如果使用人數(shù)很多、頻率很高、需求也很強烈,那當然是好需求。

如果這三者都不沾邊,可以判斷為無價值需求,可過濾掉。

需求優(yōu)先級評審為了讓開發(fā)對需求的可行性、開發(fā)難易層度做大致的評估,以及提供實現(xiàn)思路（不同的實現(xiàn)方式對邏輯流程和原型會有影響）。

部分需求可能要分期開發(fā)。

會議之后輸出需求優(yōu)先級、爭議點和難點。

開發(fā)在會后就可以開始技術(shù)預(yù)研。

需求分類方法投入產(chǎn)出比ROI：商業(yè)價值/用戶價值-開發(fā)成本要考慮需求的實現(xiàn)成本（人力、時間、資源、運營等因素）以及收益（商業(yè)價值/用戶價值）,綜合考慮是否將其納入本階段的需求庫,還是放到下一期實現(xiàn)。

馬斯洛&七宗罪需求分析法馬斯洛需求理論：生存需求、安全需求、社交需求、尊重需求、自我實現(xiàn)需求。

七宗罪：傲慢,嫉妒,暴怒,懶惰,貪婪,饕餮,以及欲望。

分別從需求的層級和人性的角度,對需求進行深層次的把握。

痛點分析法將需求分為：痛點、癢點和興奮點需求。

KANO模型分析法可以將KANO模型理解為是痛點分析法的加強版。

以分析用戶需求對用戶滿意的影響為基礎(chǔ),體現(xiàn)了需求實現(xiàn)程度和用戶滿意之間的非線性關(guān)系。

將需求劃分成如下5類：。

基本(必備)型需求–Must-beQuality/ Basic Quality 期望(意愿)型需求–One-dimensional Quality/ Performance Quality 興奮(魅力)型需求-Attractive Quality/ Excitement Quality 無差異型需求–Indifferent Quality/Neutral Quality 反向(逆向)型需求–Reverse Quality。

KANO模型。

匹配產(chǎn)品定位、產(chǎn)品目標和資源情況等限定條件,做最后一輪篩選需要考慮產(chǎn)品定位,符合戰(zhàn)略目標、目標用戶和既定的功能范圍。

做需求要為產(chǎn)品的核心功能服務(wù),不然容易功能越做越多,龐大而冗余,反而導(dǎo)致用戶流失。

確定目標用戶很關(guān)鍵,確定目標用戶,需要綜合考慮受眾群體大小、需求相關(guān)性、商業(yè)價值和已有資源。

總得來說功能要為有價值的用戶服務(wù)。

舉例：。

比如一款音樂產(chǎn)品,受眾年齡15歲到65歲都有,但你不能說目標用戶就是15歲到65歲的人群。

因為不同年齡段的受眾,甚至需求都是相悖的,興奮點也不一樣。

這產(chǎn)品就不好設(shè)計了,最后搞不好兩邊用戶都不討好。

通過分析發(fā)現(xiàn),用戶群體可以劃分為休閑放松、時尚潮流、極客等類型。

再綜合考慮受眾群體大小、需求相關(guān)性、商業(yè)價值和已有資源,你可能就選擇了休閑放松這個群體規(guī)模大、頻次高的人群作為你的目標用戶了。

當然這里是簡單介紹,每款產(chǎn)品會有不同的選擇。

但總的來說,目標用戶一定要明確,可畫像的。

定義優(yōu)先級在此之前需要判斷產(chǎn)品所處的生命周期,因為不同產(chǎn)品生命周期的側(cè)重點是不一樣的。

（1）產(chǎn)品初期（0-1）：做最小可行產(chǎn)品(Minimum Viable Product,簡稱MVP),滿足用戶核心需求,快速上線,快速迭代。

積累種子用戶。

此時產(chǎn)品不宜做得大而全,方便調(diào)整產(chǎn)品方向。

如果是內(nèi)容型產(chǎn)品,還需運營好社區(qū)基調(diào),控制用戶導(dǎo)入,比如知乎早期采用的邀請制。

（2）成長期：繼續(xù)打磨核心需求,完善功能短板,讓產(chǎn)品朝著指定方向發(fā)展。

這時候會加大運營投入,用戶大量導(dǎo)入,需求激增。

這時候團隊壓力很大,要控制好需求,把握好核心用戶,把資源用在刀刃上。

同時重點關(guān)注留存和活躍,提高粘性和使用時長。

（3）產(chǎn)品成熟期：不斷打磨產(chǎn)品,鞏固產(chǎn)品壁壘,制造興奮性需求,挖掘潛在用戶,擴大用戶規(guī)模。

同時要開始考慮變現(xiàn)。

（4）產(chǎn)品衰退期：盡量延長產(chǎn)品生命周期,持續(xù)帶給用戶新鮮感,留住用戶。

擴充品類,孵化新產(chǎn)品。

總的來說,符合當前公司發(fā)展目標的優(yōu)先級高,反之降低優(yōu)先級。

接著就可以結(jié)合重要緊急四象限,排出優(yōu)先級。

這里就需要具體情況要具體分析了,沒有統(tǒng)一評定標準。

重要緊急是很好的排優(yōu)先級方法,有的公司會進行多輪的需求評審,優(yōu)先級評審階段,在小黑板上畫出重要緊急四象限,將需求根據(jù)討論寫在白板上面。

根據(jù)需求的分布情況,優(yōu)先級就一目了然了。

當然別忘了,需求要做到什么層度,是簡單做還是復(fù)雜做,是不是分階段做。

比如登錄需求,是用三方登錄還是需要自建一套賬號體系。

比如微信登錄,熟悉的開發(fā)可能1人/1.5天就搞定了。

自建賬號體系就相對比較復(fù)雜了。

具體做到什么層度,就需要產(chǎn)品經(jīng)理自己定義了。

技術(shù)評審會議的時候,開發(fā)特別關(guān)注這個。

產(chǎn)品設(shè)計用戶體驗要素。

注：用戶體驗要素5層模型。

戰(zhàn)略層：產(chǎn)品目標及其目標用戶（做什么、為誰而做？）范圍層：功能及其內(nèi)容需求整合（需要做哪些？）結(jié)構(gòu)層：交互設(shè)計及其信息架構(gòu)（怎樣做？）框架層：界面設(shè)計、導(dǎo)航設(shè)計和信息設(shè)計（怎樣做？）表現(xiàn)層：視覺設(shè)計（要做成什么樣子？）。

產(chǎn)品設(shè)計過程：。

將需求歸納整理成用戶任務(wù)多個用戶任務(wù)交織成信息架構(gòu)將信息架構(gòu)具象化為頁面流程圖,并通過界面草圖的形式表達出來接著根據(jù)設(shè)計原理,讓界面草圖進化為頁面原型最后加點調(diào)料,通過情感化設(shè)計和游戲化設(shè)計,賦予產(chǎn)品魔力流程圖&設(shè)計草圖設(shè)計原型前,先進行結(jié)構(gòu)層和框架層的設(shè)計。

也就是流程圖到設(shè)計草圖（紙面原型）。

這一步不能跳過,前期考慮周全,會節(jié)約大量的時間,避免后面修改起來牽一發(fā)而動全身。

這個環(huán)節(jié)很多同學會去研究競品或者尋找相似設(shè)計,這本身沒什么錯,但最好不要這樣。

容易固化思維。

你要先把自己腦中想象的東西畫出來,然后再去對標競品,如果對方好的設(shè)計你可以借鑒,不好的地方那就你設(shè)計的獨到之處了。

功能流程圖在有一些比較復(fù)雜的流程的時候,怕開發(fā)人員或是設(shè)計人員不是能理解的情況下,要把流程圖畫出來。

但是一個完整的項目只用一個流程圖是不可能完成的,所以需要按照模塊的流程逐個進行分類,分類以后按照功能的不同、簡易程度,分別畫出流程。

用戶行為/用例產(chǎn)品的功能點、主要功能賣點。

界面布局文字文案、各功能描述、彈出框內(nèi)容文案,各模塊之間關(guān)系。

信息架構(gòu)各模塊業(yè)務(wù)邏輯、結(jié)構(gòu)框架圖。

原型圖規(guī)范的交互原型圖結(jié)構(gòu)由如下五要素組成：。

更新日志迭代記錄產(chǎn)品結(jié)構(gòu)圖原型圖交互說明產(chǎn)品結(jié)構(gòu)圖會忽略掉很多細節(jié),只展現(xiàn)頁面層級結(jié)構(gòu),而且只表達正常情況下的頁面關(guān)系。

目的還是為了簡單,一下子就看得懂,方便記憶。

比如,會忽略掉復(fù)雜的頁面跳轉(zhuǎn)關(guān)系,而只表達主干道上的頁面流程。

會忽略掉眾多的狀態(tài)判斷,而只表達正常情況的頁面流程。

原型圖。

好的原型工具有Axure RP、墨刀等等,學一款原型工具很簡單,找個視頻看一下,10分鐘就會了。

重點在于要把自己的想法通過原型表達出來。

原型也是跟視覺、開發(fā)和測試溝通的橋梁。

原型有低保真和高保真,甚至動態(tài)原型圖之分。

這個看團隊需要。

UI設(shè)計&UI評審視覺設(shè)計交互設(shè)計一旦通過,就可以進入下一步的高保真圖的設(shè)計,視覺設(shè)計組會根據(jù)產(chǎn)品經(jīng)理的描述,設(shè)計出最新的視覺效果(高保真圖),一般采用ps等設(shè)計軟件。

在交互評審?fù)ㄟ^后,負責把控UI整體風格和所有視覺效果的設(shè)計,主要輸出：VI選擇的方案、所有視覺效果圖、資源包等。

功能/操作界面交互設(shè)計（規(guī)范）需求評審會議拉領(lǐng)導(dǎo)、開發(fā)、視覺、測試等多方參與。

評審內(nèi)容以原型圖為主。

第一次需求評審會議,需要給團隊介紹產(chǎn)品目標、目標用戶、設(shè)計思想等等這些問題,確保大家目標一致,思路統(tǒng)一。

會后同樣也要輸出原型修改點和爭議點等等這些內(nèi)容。

一般需求評審會議開個幾輪都是正常的。

有的公司要求在需求評審階段就要輸出PRD文檔,有的公司不鼓勵寫PRD文檔,畢竟寫PRD文檔也是一項耗時的工作,開發(fā)還不一定看。

當然,這因公司而異。

PRD文檔（Product Requirement Document）PRD詳細需求文檔一般與視覺設(shè)計是同步進行,主要是細化MRD里的功能以及詳細流程、文案等細節(jié),主要還是產(chǎn)品經(jīng)理負責。

PRD詳細需求文檔,一般包括功能流程圖 、產(chǎn)品的功能點(框架腦圖)、主要功能賣點,模塊的內(nèi)容,文字文案、各功能描述、彈出框內(nèi)容文案,各模塊之間關(guān)系,以及各模塊業(yè)務(wù)邏輯、結(jié)構(gòu)框架圖等。

涉及到負責的流程,需要完整的流程圖,需要按照模塊的流程逐個進行分類,分類以后按照功能的不同、簡易程度,分別畫出流程。

開發(fā)上線開發(fā)排期開發(fā)排期技術(shù)負責人會把控,但產(chǎn)品作為總協(xié)調(diào)人,需要統(tǒng)籌開發(fā)和視覺進度。

開發(fā)和視覺同時啟動,這沒什么問題,但視覺進度一定要快于開發(fā)進度,這是肯定的。

開發(fā)排期有粒度的概念,即開發(fā)會將需求拆分成小的功能點,每個功能點完成時間是以天為單位、0.5天為單位還是以小時為單位。

這個時間單位就是粒度。

這就需要產(chǎn)品去要求開發(fā)同事了,不然他到時排期給你個以周為單位,這就沒有多大指導(dǎo)意義了。

顆粒度越大,進度越不可控。

因為開發(fā)過程中,有很多不可控因素,比如中途插入更高優(yōu)先級需求,這時候你需要清晰的知道,在哪個環(huán)節(jié)延誤了,已經(jīng)延誤了多長時間。

以方便及時調(diào)整開發(fā)計劃。

一般大的功能點可以以天為單位,小功能點以0.5天或小時為單位（比如需要及時響應(yīng)的運營需求）。

開發(fā)項目跟進有點類似項目管理,協(xié)調(diào)資源、催進度（周啟動會議、周總結(jié)會議）、關(guān)心開發(fā)實現(xiàn)上的問題、安排好后續(xù)測試和上線環(huán)節(jié)。

這些都是分內(nèi)的事。

所以也不是人人都是產(chǎn)品經(jīng)理啊,產(chǎn)品經(jīng)理要求還是比較全面的。