99久久精品费精品国产一区二区,日本三级理论人妻中文字电影,欧美人与动交片免費播放

搜索

APP

起點課堂會員權益

職業體系課特權

線下行業大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業技能直播

會員專屬社群

榮耀標識

發布

注冊 | 登錄

歪果仁說產品｜MVPM—產品經理也有MVP模型

汪仔3386

2017-07-11

8 評論 13932 瀏覽 113 收藏

29 分鐘

全文約7000字，讀完本文大約需要10分鐘，此文為英文譯文

從三個圓說起

下面這張圖也許你在以前就見過，它既簡單而又優雅的展現出了產品經理本身是眾多技能交集體。

這張簡單明了的數學集合圖，恰如其分的說明了產品經理應該擁有的技能以及其內在的能力界限，非常完美的詮釋了一個產品經理應該擁有的能力模型。

在很久以前，作為一個產品菜鳥，這張圖告訴我必須自覺地學習各種各樣的知識和技能從而去構建自己的技能樹的廣度。但是，它似乎沒告訴我，我到底應該專注在什么地方；所以，在最開始作為一個小白時，我總是狼吞虎咽的學習著所有我能接觸到的知識和技能。到頭來，卻發現這是一個天大的錯誤。

很顯然，在這個地球上我們是沒有足夠的時間去學習上圖中那三個圈里面的所有知識和技能的。圖的展現的東西雖然很有用，但終究來說卻是不切實際的。

所以，如果我們要讓這張圖對我們有所幫助，我們應該先了解清楚，圖里面交集的部分到底包含了什么？

交集的部分就是我要說的MVPM，即最小可行的產品經理（Minimum Viable Product Manager）。MVPM完美的定義了一個合格的產品經理應該擁有的知識和技能。

但MVPM并不意味著你需要很快速地去精通其中提到的所有技能，這樣對于一個小白來說不但不切實際，而且還會有適得其反的效果。相反，你應該把它看作一個小白產品經理剛入行學習的教學大綱。

這篇文章，寫給過去那個年輕的自己，寫給產品小白，同樣也寫給那些希望提升自己的產品老鳥。為了和上面那張圖里面的三個圓一一對應，我將我要說到的點分為技術、商業和用戶體驗三個大點進行描述。并且，每個大點相對應的指出三個必須聚焦的知識或技能和一個不能踩的坑。為了讓更多的小白和行外人能快速讀懂，我將盡可能描述得通俗易懂。

一、MVMP：技術

1.技術棧

當程序猿們在談論技術棧時，程序猿們在談論什么？

“技術?！笔且粋€相對抽象的概念，它可以泛指用來實現你的產品功能的各種前后端技術，它讓一切產品需求得以實現。從一個用戶加載到你的產品的登錄著陸頁，到他主動地把他的用戶賬號注銷，技術棧都默默地在背后處理著這一切。

如何快速學習——請教開發大神們，讓他們幫你從“一覽眾山小”的角度去review一遍所有的技術棧。接著把你聽到的各種技術記錄下來，并且快速的谷歌一遍所有的專業術語。這樣，你就會大概了解到產品開發中所用到的每種技術的優點和不足之處，也會清楚這些技術在內部是如何和諧并高效地運作的。記住，在快速了解技術時一定要以“一覽眾山小”的角度切入，否則你會掉入技術學習這個大坑無法自拔。

成為一個更好的PM——當程序員們在辦公室里討論產品架構應該如何搭建，頓時，各種專業術語總會滿天飛。這時，也許你會一臉懵逼。但是，當你了解了技術棧的相關知識，這意味著你可以跟得上他們討論的節奏。假以時日，你將會逐漸明白程序猿們到底在討論哪一個層面的技術問題（比如，是前端的問題還是后端的問題；是數據庫的問題還是服務器的問題…）。通常來說，一個產品的技術棧中需要接觸的東西越多，涉及的層次越深，那么這個產品的需求變更后的開發難度就越大，風險也更大。當你了解了這一切，在下一次考慮如何解決產品問題時，你可能就會用另一種方法去解決問題。

2.系統架構

如果說剛剛提到的“技術?！贝碇切┙洺１晃覀兪褂玫降募夹g，那么系統架構就控制著這些技術如何共同搭建，高效運轉，并最終誕生出產品的。與更抽象的“技術?！北绕饋恚到y架構則更加貼近于產品本身，它的設計構想恰恰會體現出用戶的產品需求。

如何快速學習 ——同樣的，還是要請教開發大神們，讓他們給你畫一個系統的架構圖，那么你將會得到類似一張這樣的圖：

在看到這張圖后，你懵逼的概率達到了百分之99，但是，一定要蛋定。首頁，你必須跪教（跪著請教）程序猿大哥們，讓他們告訴你圖中所有不同形狀的組件（包括各種客戶端、服務端及數據庫）都是干什么用的；如果你請教的姿勢是對的話，那么，他們會告訴你哪些東西是用來處理網絡請求的，哪些是用來實現業務邏輯的，哪些是用來儲存用戶數據的。

當然，你不要作死的認為程序猿哥哥在忽悠你，他剛剛說的一切對你都是非常有用的。

成為一個更好的PM——當你大致了解了系統的架構后，你就會逐漸的像程序猿們一樣的把你的產品看做一個系統來去思考。這樣，當你清楚的了解了產品中的每一部分在總體中起的作用時，你就會做出更好的決策和需求權衡，在考慮需求方案時，會更加的周全以及更加清楚它的可行性。

一般來說，如果一個產品中的某個模塊與系統的其他模塊的關聯越多，那么它的變動則會越復雜和困難，因為產品中的其他模塊都要依靠它來提供數據傳輸或是功能支持。如果在實現某個功能的時候，你的產品需要改變的模塊越多，對外部的數據或功能依賴越多，那么，你的這個功能將會很難執行并實現。

在大公司里，產品執行工作中涉及的不同模塊的數量通常是和你要去溝通的部門或團隊的數量是一樣的，所以，這也意味著你要獲得同等數量的人的同意和支持。

3. 數據結構和API

數據結構負責把產品中用到的各種數據高效的組織起來，并且標準化了這些數據是如何與其他“信息”關聯起來的。而這里說的“信息”指的是用戶、產品、信用卡等等，那些具體的東西。這些東西通過確定的、結構化的方式相互關聯，例如一個用戶可以擁有很多的產品，但通常情況下只有一張信用卡。

數據結構與上面說到的系統架構有非常緊密的聯系，之所以這么說，是因為特定的數據信息是存放在特定的系統模塊中的。你的用戶信息以及與用戶相關的產品數據可能存放在A模塊中，但是由于用戶隱私信息的敏感，信用卡信息可能會存放在B模塊中。所以當你有一個需求是需要將一個產品擁有的用戶的信息展示在一個列表中時，那么這將相當簡單，因為這些信息是存放在同一個模塊中的。但是，當你需要知道這些用戶當中哪些用戶綁定了信用卡時，A模塊就需要與B模塊進行關聯，以此達到數據傳輸的目的。這樣做有一定難度，需要用到API來去實現。

API是建立在數據結構之上的，它體現了不同的兩個模塊（前后端）之間在是如何進行通信以及做數據傳輸的。更重要的是，API也可以讓你與第三方（外部模塊）進行數據上的通信。當你在谷歌地圖上叫Uber時，谷歌地圖則會調用Uber提供的API，與Uber的相關模塊進行數據通信。大多數的產品會有它的“公共API”和“私有API”，“公共API”是產品開放提供給外部所有人都能使用的API，也就是我們經常會用到的“第三方API”，“私有API”則是我們自己的產品使用不對外公開的API。

如何快速學習——第一時間去了解你產品開放或提供出來的一些API。這些API大多數都很容易找到，它們大多數存放在產品開發文檔下的API接口文檔中。當你看到這些API接口文檔時，你會看到上面寫著一些代碼，這時，你到底會不會被這些代碼嚇一跳將取決于你的背景知識；但是，如果API接口文檔寫得比較規范的話，你還是會比較容易讀懂它們的，畢竟他比寫在程序上的代碼還要簡單。API通常常體現了一個產品的內部數據結構，這樣，當你研究完API時，也會對產品的數據結構有一個大致的了解，可謂一石二鳥。

成為一個更好的PM——了解清楚產品的數據結構，它可以擴展你的能力，讓你知道你可以利用哪些信息來創造出更好的產品，同樣的，你也會清楚獲取該信息的難易程度，自己心里會有個底。了解清楚產品的API意味著你也了解清楚了你的合作伙伴和第三方開發者會從你這里獲取到什么樣的信息，所以你也應該知道產品上哪些外部合作或是可行的。一個產品擁有的可擴展性是其最具有價值的屬性之一，一個產品能與外部的產品（你的用戶每天都在使用的產品）進行良好的協作變得越來越重要。

4. 不能踩的坑

別去敲代碼。先別誤解我的意思，我也喜歡敲代碼，他確實也讓我變得更加專業；但是，除非你負責的是一個包含著黑科技的產品，否則你不需要依靠敲代碼來去成為一個好的產品經理。如果你正以產品經理的身份去敲代碼，你就要問問你自己是不是在干著一份高回報的工作，又或者是你根本不知道自己應該做些什么。但是話說回來，我覺得一個人至少開發過一次APP產品或是Web產品，并把產品部署到生產環境上，那么這會是一次值得而又好玩的經歷。

二、MVPM：業務

1. 項目管理

我知道這很枯燥，我也不喜歡做項目管理，但是它卻非常重要。如果你不能很好的運作管理一個項目，那么你將永遠不能成為一個好的產品經理。

如何快速學習——這是一件很困難的事情。想要成為一名好的項目經理，一方面需要大量的經驗和時間積累；另一方面，項目管理是一個關于人際處理的問題。你需要發時間去了解那些跟你一起工作的同事的性格，而你要怎么樣跟你的同事交流同樣也取決于你的性格。

話雖如此，你還是可以學習一些軟件方面的知識來去加速積累你的硬技能的。

了解產品開發過程中的基本知識，這樣在和團隊共同工作時你將會有更多換位思考的能力。學習版本控制的知識和技能（比如GIt）、了解協同開發的工具（比如GitHub）、了解質量控制（QA）的流程，最后還要知道你的產品是如何以及何時部署到用戶手上的。
2.了解那些常見的困擾團隊的問題，并且要知道解決這些問題的方法。在項目管理的過程中，你也許會遇到一些新的項目管理方法，例如敏捷開發流程、Scrum開發流程、看板開發流（具體意思可自行Google）。不管你的團隊有沒有用這些項目管理方法，他們背后的哲學精髓都是值得你去學習的。
3.了解清楚團隊的決策方式，弄清楚你的利益相關人。一般情況下，他們可能會是你的用戶、你的老板、團隊成員的上司，亦或是其他產品經理。確保團隊中每一個人都清楚自己工作的進展和未來的方向，同時也要讓同事們清楚他們關心的事情的進展和方向，或者你去了解清楚他們到底關心什么。

成為一個更好的PM——你可以和你的團隊一起做出更多有趣的事情，這樣你的同事也會更喜歡和你一起工作，因為大家都不會喜歡一個管理不善的項目。

2. 業務模型分析

工作上的事情如果沒有事先做好計劃和估算，是很少可以出色的完成的。產品也一樣，任何一個產品都應該定下一些關乎產品成功的量化目標，例如用戶增長量、產品功能接受度、產品收入等等。

當你的團隊在爭論著下一個版本應該優先上什么功能時，如果你能為產品提供一個指導產品發展方向的參考模型就顯得十分重要了。

如何快速學習——所以，是時候建立一個產品發展的參考模型，一個好的模型應該清晰的展示以下兩點：

產品建設成本的預估：

獲取一個新用戶的成本是多少？
產品的運維成本是多少？
實現產品的每一步目標需要的成本是多少？

產品未來發展的狀況預估：

未來一年產品會怎樣一步一步向目標發展？未來三年呢？
團隊需要招聘多少人來去支撐產品的優化和運維？
長期來看市場力量對產品會有怎樣的影響？例如成本下降、通貨膨脹以及行業競爭等等。

成為一個更好的PM——正如以上所說到的產品發展模型分析，如果你經常練習去為你的產品建立這樣的模型，那么這將是測試你的產品發展預估模型的好方法，也能確保你的產品有足夠的發展潛力讓你值得為之付出。另外，它還可以讓你的工作變得更加簡單，讓你的項目更能說服的你的利益相關人，讓你和其他項目比較它們的機會成本。

3. 數據收集與分析

一個團隊如果能夠用獨立的收集各種數據，那么對于團隊做出快速決定是非常重要的。對于那些復雜的數據分析，依賴其他人來幫你你收集數據不但是浪費別人的時間，而且這樣也不會讓你領會到數據的真正作用；因為那些懂得做數據分析的人都知道對數據的理解和敏感度是通過不斷對數據的挖掘和分析養成的，而并不是你天天看著PPT里那些漂亮的圖片就能學會的。

依賴別人來去收集和分析你的數據同樣也會削弱根據數據來去做決定的能力。幾乎每一天我們都在決定著產品在某個特定的用戶場景應該如何去設計，這時有數據作為支撐的決策就會變得很簡單。

如何快速學習——你的終極目標是做到可以通過自己的能力獲取產品的數據。當然，你是要通過寫SQL語言還是通過拖拽控件來獲取數據就要看你的產品采用是怎樣的數據技術支撐。不管用什么方法，你還是需要投入時間去學習相關獲取數據的工具，自己找時間谷歌吧。

成為一個更好的PM——當數據很容易獲取時，你就會更加頻繁地使用到它。不管你是考慮著產品的下個版本應該做什么，還是看看產品的進展如何，你都會形成條件反射，會把數據作為你做決策的重要輸入，而這樣你的產品將會變的更好。

4. 不能踩的坑

一個有著商業學位的朋友給我的教訓：不要把你的時間浪費在做什么商業策略、三年計劃、或者其他MBA的事情上。雖然我還不至于跟你說這些東西啥也不是，但是可以肯定的是這些東西在做產品上是不怎么行得通的。

弄清楚產品的愿景，找到實現愿景需要解決的問題，想出解決問題的辦法，然后盡快地通過用戶來驗證你的辦法，并不斷重重復以上步驟。

三、MVPM：用戶體驗

1. 了解產品的設計模式

大部分產品經過長時間的打磨后，都會形成自己的設計模式，不管你有沒有刻意地去規劃它。設計模式是指在產品中一直使用著的相同的視覺效果和交互組件。

“產品按鈕上的字體使用25號大小的字體；所有的表單都不超過3個字段；每次的報錯都會有一個爆炸的音效反饋，并給用戶發送一份關于這個錯誤細節的郵件?！薄@些都是設計模式。

了解產品的設計模式是讓你清楚你的用戶是如何理解你的產品以及讓他們很快的接受你的產品的新功能的關鍵。如果你以前都是用綠色的寫著“添加新功能”的按鈕，通過點擊來啟動某些功能，這次你把它換成了橙色的寫著“來點新意”的按鈕，這樣你可能會把用戶搞暈的。

隨著產品的不斷成長，運用一致的產品設計模式將變得越來越重要，因為這樣既能夠樣產品團隊中的每個人獨立地工作，也能夠讓產品看起來更加渾然一體。

設計模式一般是會和技術模式相互和諧發展的，像一些樣式或是前端組件，技術都是可以拿同樣的代碼來復用的，這樣開發的速度和效率都會更高，因為他們不需要再去設計或是實現一個同樣的功能了。

如何快速學習——?請教一下你們的設計師，他們都應該知道這些設計模式，當然也希望他們能給你一份設計模式的相關參考。同樣的，請教一下你們的前端工程師，他們也會給你一個關于設計模式的相關參考。

成為一個更好的PM——?坦率地說，使用設計模式會讓你產品工作更加簡單更加快速。設計模式讓你站在設計大神的肩膀上，以至于你的產品做得非常簡單易用。如果你想打破產品現有的設計模式，你必須想清楚為什么要這么做，準備好向團隊說清楚為什么這么做對產品的長期健康發展是有必要的。

2. 知道怎么做用戶體驗調研

產品經理應該代表著用戶的聲音。如果你不懂你的用戶，你永遠也不可能打造出牛逼的產品。從做一個面對面的用戶訪談，到量化分析數以萬計的產品行為，了解清楚做好用戶研究的基礎，對你的工作來說是非常必要的。

如何快速學習——有用的研究是一個非常大的領域，所以避免把你引到一個大坑里去，我推薦你搞懂以下幾點：

了解清楚研究樣本的大小，知道怎樣計算統計結果；
了解清楚怎樣讓你的樣本更具代表性，以及它為什么如此重要；
了解清楚在調查和采訪過程中如何提出不帶偏見、不具誘導性的問題；
了解清楚如何得出全面的研究結果并避免得出錯誤的結論。

成為一個更好的PM——通過頻繁地與你的用戶一起測試你的產品，你可以打破很多產品開發中的猜想。在一個項目開啟之前，你應該測試驗證一下你想要解決的問題或是需求，是真的需要被解決的。當你在設計和開發產品時，你應該測試你設計的產品是否是易用的，并且它能不能夠幫助你的用戶解決問題。在產品上線之后，你應該驗證你幫助用戶解決的問題是不是真的解決了。

3. 知道怎樣把你的想法輸出為原型

這里所說的原型是指能夠做出可以高效表達你的想法的產品視覺原型草圖。原型做得足夠好，你就能做好以下幾點：

清晰的表達出產品的概念：

要傳達好一款產品的體驗，無論是從口頭表達還是書面表達，都是非常困難的。而一個可以讓人們看到產品大致樣子的原型（最好可以加上交互效果；你不需要寫代碼就能實現這一切）會有效十倍。
之所以這樣，是因為有兩點的原因：一、產品原型可以清晰地描述用戶最終如何與產品進行交互；二、因為人類天生喜歡視覺化地思考，可視化的原型可以拉平不同領域的看法和差異，以至于團隊里的每個人都可以用共通的語言來溝通，并高效地給出自己的意見。

在必要的時候幫設計師一把：

在大多數項目中，產品設計走在產品開發的前面是非常重要的。設計師努力“跑在開發的前面”，因為一旦開發人員按照既定的方向去開發產品，之后產品方向的變更產生的成本將會很高。
因為很多產品的設計都是需要不斷的迭代并且是與產品開發并行的，當產品設計遇到瓶頸（例如，用戶調研證明設計是不夠好的），設計的進度就會很快的落在開發后面。遇到這種情況的時候，產品經理就應該能夠馬上卷起袖子充當設計師的助理，讓設計圖能夠按時交付，保證產品的開發進度。

如何快速學習——這個我就不花時間說了，趕快把Sketch用起來吧，它就是微軟畫圖和Photoshop的完美結合、一個神器。

成為一個更好的PM——通過原型，你可以告訴人們你在想什么，而不是假裝他們已經懂你的意思了。同時，你也會從你的同事那獲得更多更好的反饋，也減少了溝通不暢導致的人力浪費。

4、不能踩的坑
別想著去做一個牛逼的視覺設計師。也許你有能力去設計出很漂亮的交互界面，但是這是多余的，這樣打消那些深入研究產品設計的人的信心的。除非你真的是一個設計大牛（需要清除的是，大牛永遠是稀缺的），否則當你以為自己還不錯的時候，可能你真的啥也不是。