起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品的“加減法”，究竟該依據什么做？
東東導讀：當我們說起一款產品的發展史時，我們總偏向于它的成長和性能的增加。其實很多時候，剔除那些不必要或者“劃不來”的性能，將資源挪用在別處也是產品發展的關鍵。畢竟，要制作產品，最重要也最艱難的是：把它做得更精簡。
當我們說起一款產品的發展歷程時，我們主要關注的往往是產品是如何制成的，途中增加過哪些性能，還有產品的發展以及成熟的過程。這確實挺好，但根據我創造Quibb的經驗，我發現剔除多余的性能也是產品設計和經營的重要方面之一。
怎樣才能讓產品不那么臃腫，把產品做得更簡練，更生動，這種事從來沒有太確切的指南或者指標。我已經見過太多成熟的公司移除產品的各種性能了。他們要鑒別、區分、權衡產品的每一個功能，然后做艱難的決定——應該移除哪個功能。只有這樣，他們才能達成“制作更好的產品”的目標。
用戶vs開發者
倘若一款產品的某個現存的特征正處在存亡關頭，那我們審視的時候就有必要把這個特征對于使用者的影響和對制作者的影響分開看待。雖然大多數情況下顧客和公司的目標是相同的，但也不全然是。
Quora曾在幾年前遇到過這樣的窘境。當時問題出在Direct Question這個功能上。Direct Question是讓用戶直接通過人物主頁向Quora用戶提問的功能。
對用戶而言，這個性能放低了門檻，節省了麻煩。他們可以通過這個功能向某位特定的用戶直接提問。但這個功能最后被移除了，因為公司發現如果用戶之間可以直接提問，那么很多有價值的信息就不會出現在Quora的問題主頁上了。
這個性能就是個典型的例子：它對用戶來說是十分便捷的，但卻對公司創造的有價值的內容造成了不利。
真實用戶vs理想用戶
那些你所定義的“目標人群”用戶往往不是你的產品的第一批使用者。也許你很了解他們，也有可靠的理由證明為什么你更傾向于你“理想中的用戶”，而不是他們。
一款產品的用戶使用時間是有自然期限和循環的（也就是早期和后期用戶），但最重要的是你不能被早期用戶的特性左右了你的原定計劃。你要繼續保持產品的特點，根據你一開始鎖定的“目標人群”繼續創造和改善它，增添新的性能。既要為早期用戶著想，保留他們喜愛的性能，但也要針對你后期的用戶繼續精心打造產品。你要在這兩者間拿捏好分寸。
因為給一款產品增添過多的性能往往意味著你日后需要移除它們。
移植vs移除
近日，開發者有對權衡的問題愈發敏感的趨勢。他們不再徹底剔除某個性能；他們選擇把這些性能轉換為新的產品。
Dropbox就用過這個方法開發了照片分享專用軟件Carousel，Facebook也同理推出了Messenger，Foursqure則是Swarm。盡管我們中大多數人做不到如法制炮模仿這個戰略，但它為我們強調了保持產品簡潔生動的重要性——尤其是裝載在手機上的應用。
手機版vs網頁版
近日來，我和幾位智能產業的創業家談了談。他們都想把他們的第一款網頁產品改造成手機專用版。由于手機版和普通瀏覽器版產品的運作方式實在差太大，兩者之間無論是外觀還是使用模式都截然不同。
設計產品是究竟應該從手機版應用上刪除哪些性能，這對于制作人來說也是一個令人頭疼的問題。Twitter在這方面就做得很好。先看看其網頁版應用。網頁版覆蓋的面較廣，子菜單項高達13個。
開發者也意識到要把這么多設定都加在手機版上的話那使用太過麻煩，應用本身也難免顯得臃腫。Twitter不得不做出決策，把具體哪些功能剝離開來保留在手機版應用中。
要權衡在某個平臺上移除產品的哪些性能總是一個艱難的決定，因為你需要把產品做得盡可能精簡，但用戶體驗又不亞于你產品的其他任何一個版本。
于是就有了技術方面的挑戰……
當你權衡功能的去留并做決定時，你必須顧慮到每一個細節，再三斟酌。而且幾乎每一個功能都是有現實的技術限制和要求的。
每當你在制作一個新的功能的時候，你就等于是和產品的未來定下了條約：你要讓你現在所編寫的東西到了將來也不會過時，而且能和你以后增添的性能兼容。區區幾個新功能就能讓一款簡單的軟件對人的依賴性增大，資源人力有限的制作團隊可能會力不從心。
支持的OS版本，加載時間，遺留成本，定標等等等等，對于軟件的功能我還能舉出好多好多。很多時候，減少技術上麻煩的部分，或者剔除效果不理想的功能的真正意義在于大幅度節省資源，好將有限的資源用在現存的、更受歡迎、更有前途的性能上。
Quibb早期的功能里有一項是用來解析那些非Quibb用戶但現存Quibb用戶關注的Twitter用戶的個人簡介。如果我能把他們的公司名對上號，那我就可以基本確定他們是同事，所以那個人是他們會邀請的人。
但過一段時間后，我意識到這個功能會引發不少問題。用戶們紛紛抱怨他們的消息加載速度太慢。在權衡利弊之后，我刪除了這個功能。當時我沒有足夠的資源來彌補這個問題好讓軟件能靠有限的技術含量更好地運行，而且僅有的資源有更好更有價值的用途。
歷史證明，在一定范圍內，對任何一位產品設計師而言，精簡二字是最艱難的任務之一。
這篇文章是我在讀了Ben Horowitz的“Good Product Manager，Bad Product Manager”（好產品經理和壞產品經理）后有感而發。其中有一句話讓我感觸頗深：“一位好的產品經理總能一針見血地看清并定下目標?！?/p>
來源：獵云網
- 目前還沒評論，等你發揮！
