想做的事情很多，但是要結合現實(資源和能力)，但是這可能還不夠，還要考慮競爭者，是不是你要做的事情別人更有優勢，是不是他們很容易超越你，這些因素都要考慮進去，最終得到能做且能做好的事情，目標明確。但是這取舍還不夠，接下來進行時間的取舍，也即所謂的輕重緩急，什么事情是現在不做不行的，什么事情是可以放放的。

按照半年一個周期的話，會把前面幾個月作為重點突破，先交付出可供試點或內測的版本，此時注重的是商業模式的清晰，定位的清晰，之后穩打基礎，做一些重的事情，第三個階段加強運營和體驗優化。

最近看到另外一句話，分享給大家：think big, start small, do smart.

2. 抽象能力

記得當時剛轉崗做產品經理的時候，去給一個大神級的人物匯報產品方案，該神人動輒提到：抽象化，不要聽太具象的，就是讓我講一些抽象的概念。

當時不理解，你們扯來扯去不就是最終要看產品原型嗎?現在原型都有了，還要抽象干嘛?

在后續的工作中，即使沒有人再耳提面命，自身也體悟到抽象思維的重要性。難怪有人常說：把事情想復雜了，很容易，但是把復雜的事情想簡單了，是個更需要功力的活。

把事情想太簡單或者太復雜，可能都不夠有功力，真正的高手就是要把簡單的事情先復雜化(全面、周全、系統)，然后——抽絲剝繭，再把復雜回歸到簡單。

從簡單到復雜，體現的是系統化，全面性。

從復雜到簡單，則更多要進行抽象化思考。

抽象就是從表面看到本質，從片面看到整體，然后抽出那些穩定的、共同的特征。

平時我們會考慮代碼的復用性，組件的復用性，同一個功能對不同場景的復用性，有了復用的能力，就能夠用更少的開發去滿足更多場景的同類需求問題?？紤]復用性或者便捷的拓展性，是產品經理必須要考慮的。

其一，我們的產品要滿足的是一個需求類別而不是具體的某個需求。從而能夠從一個具體的需求，看到一類的需求，看到衍生的相關的需求，甚至再對需求進行分類，看到更高層面的需求。進而才能夠系統性解決同類的需求而不是就事論事點對點解決問題。

其二，產品經理要考慮投入產出比，讓最小的投入取得最大的效益，所以每次的投入都要試圖解決一類問題，或者多個類的相關問題，不能夠處理具體案例就了事了。

有開發背景的產品經理對比設計出身的產品經理而言，抽象能力普遍要好一些，因為開發的一些專業課已經對此進行過系統訓練，比如UML,比如系統架構。

而設計出身的產品經理，原本的優勢恰恰在于將抽象的思維具體化，讓更多人明白到底是講的什么，畢竟面向用戶，是無法抽象化的。而恰恰是這個優勢，凸顯出了一個思維上的不足，那么就是抽象化能力上的略微欠缺。當然，我們可以能夠更加擅長使用概念圖(concept map),以及講故事(story talking)將思維具體表達出來。在講故事或者圖像化的時候，也是一種對具體案例進行抽象歸類的提煉。

我對于想要提升抽象能力的人，經常建議：畫圖吧，講不清楚畫圖吧。但是，我強調的畫圖，萬萬不是線框圖，ps視覺圖。這種圖反而頓時從抽象到具象了，這圖一定是架構圖或概念圖。

前天，還和一個開發討論某個產品的架構，我對著密密麻麻的文字說：你畫個架構圖出來看看吧。該同學說：有圖確實會直觀些，但是畫圖會比寫這些文字多好幾倍的精力。

我說，圖不是單純為了直觀，畫圖本身是一種理解、提煉、加工、組織的非常好的思維過程。圖本身可體現：次序、輕重、層次、關系……這些多維的信息，單純通過語言的描述，很容易避重就輕，講到云里霧里，講的人和聽的人都不自知，其實通過圖則直接了當地可表達出來這些多維信息。畫圖過程本身就是一個抽象思考的過程。

大道至簡，只所以到最后簡了，正是因為抽象。

PS: 平時多看看一些concept map 圖，有助于提升抽象能力，最近google不好用，換bing來學習學習

注：概念圖(concept map)是一種用節點代表概念，連線表示概念間關系的圖示法。概念圖的理論基礎是Ausubel的學習理論。知識的構建是通過已有的概念對事物的觀察和認識開始的。學習就是建立一個概念網絡，不斷地向網絡增添新內容。為了使學習有意義，學習者個體必須把新知識和學過的概念聯系起來。Ausubel的先行組織者主張用一幅大的圖畫，首先呈現最籠統的概念，然后逐漸展現細節和具體的東西——百度百科

　　關于這塊，本人還需長遠修煉。

　　本文作者?heidixie