產品設計的「節奏感」該如何把握？

01-08

說明一下，這裡的產品設計主要指的是APP開發。在APP開發中，版本迭代的「節奏感」很重要，每個大的版本迭代時結合產品計劃、用戶規模、市場環境要改進什麼功能，這些該如何把握？有沒有什麼優秀的產品案例可以探究參考？

從鵝廠到ThoughtWorks兩年了，從原來的只是畫畫線框圖到現在可以帶領團隊一起交付產品，對產品節奏感的體會與日俱增。在「騷窩」里浸潤著學到的敏捷開發也讓我明白如何從技術執行層面支撐產品的有序發布。做產品就是在用戶需求的戰場上攻城略地，而節奏感就是每一次衝鋒時的默契。

為什麼產品成長要有節奏感

在開始討論之前，我們可以先將「產品的節奏」定義為「產品更新的時間間隔以及每次更新的內容」，以便讓大家對頻率有一個統一的概念。一個成長中的產品需要不斷根據業務需求和用戶需求來更新產品。形成穩定的產品更新節奏無論是對產品的成長、對用戶、還是對團隊都會有很大的益處。

對於用戶來說，以穩定的節奏感來更新產品可以：

把團隊新實現的產品價值周期性地交付給用戶使用。
讓用戶感知到產品的不斷成長，容忍暫時的不足，對新版本形成期待。
重新激活部分已經流失掉的殭屍用戶。

對於團隊來說，穩定的節奏感帶來的好處也很多：

保持穩定更新的責任可以督促團隊儘早展示新功能，避免閉門造車太久，走偏了方向。
產品經理可以不斷推出一些新功能給用戶做實驗，驗證猜想。
團隊可以持續地收到用戶的反饋，好的反饋可以鼓舞士氣，差的反饋可以激發調整的動力。
團隊內可以形成有默契的合作方式，產品經理、設計師、開發、測試都明確地知道什麼時候該做什麼什麼事情。

節奏感應該怎麼控制

既然剛才已經將「產品的節奏」定義為「產品更新的時間間隔以及每次更新的內容」，那麼控制節奏其實也就是這兩點了。確定產品更新的時間間隔相對容易。對於移動端的產品，由於每次更新都需要iOS版給Apple審核，用戶每次更新都需要重新下載，所以定在3~6周發布一個對外的版本比較合適（緊急修復嚴重bug不算）。如果產品處於快速增長期，這個時間還可以進一步縮短。比如「打車大戰」時的滴滴和快的，新功能晚一步發布就是個死。

更關鍵的其實每次更新哪些內容。如果定好4周一個周期，那就意味著一年也就12次更新的機會。產品經理的職責就是要想好如何帶領一幫兄弟們打好這12張牌。如果每次更新都像adobe reader一樣，凈都是些個讓用戶提不起興趣的bug fix，畏畏縮縮的，那這產品也還是不要做了的好。如何籌謀好每個版本，體現了一位優秀的產品經理運籌帷幄，決勝千里之外的掌控力。

在規劃每個新版本的內容時，可以有兩種選擇：開疆拓土和持續優化。開疆拓土是指產品要完全開闢一個全新的疆域，覆蓋全新維度的用戶需求場景，野心勃勃，酣暢淋漓。剛剛把一塊地佔穩了後，這塊土地上還很荒蕪，後續還需要做很多持續改進的工作來搭建關聯輔助的功能，優化產品體驗，把這塊荒蕪土地上的生態系統建立起來。只要妥善處理好這兩種形式的新版本，讓它們相輔相成，產品成長的框架就有了。

開疆拓土是最能體現一位產品經理創造性的地方。它往往意味著從0到1( Zero to One (豆瓣) )去創造出一個有價值、有市場、為產品帶來廣闊成長機遇的新空間。Facebook圈完關係鏈然後搞社交遊戲；GoPro先做運動攝像機，然後搖身一變成為媒體公司搞體育直播；滴滴/快的搞完打車再搞專車；微信先搞定了熟人通訊，然後用搖一搖來打陌生人加好友，接下來是朋友圈分享，再來搞公眾賬號、支付、遊戲分發。這些都是積極進取，從無到有創造價值的典範。同時，開疆拓土也意味著在走少有人走的路，沒有經驗可以借鑒，風險的坑遍地。千萬不要抱著「憋個大招，打磨完美再拿出來嚇死他們」的心態來做開拓性的新功能。務必遵照精益創業的思想，用盡量低的成本在短時間內先發布基本能用的版本，然後再看後續的反饋做調整。你看微信的對講機、視頻聊天、小視頻這些，不也都不溫不火的嘛。

持續改進是從0到1之後的從1到n的過程。這部分比較簡單，因為只要前面從0到1這一步走對了，後面就可以根據用戶反饋來被用戶推著走了。用戶們缺乏足夠有深度的思考，想不到更快的馬可以被福特汽車所取代，但坐過福特汽車後吐槽減震太爛了、太TM費油之類的能力還是有的。在改進型版本里，主要是做好這幾類事情：

優化粗糙的界面設計的體驗

可用性測試啊、用戶反饋、轉化率漏斗的追蹤啊之類的都輪番上就行了，比如餘額寶大受歡迎後餘額寶主頁對每日收益的優化

增加跟核心功能相輔相成的功能

比如微信里更快更方便地通過各種渠道加好友，滴滴裡面加各種打車的優惠券。

增加讓核心功能更好用的瑣碎小功能

比如微信里聊天可以置頂、可以搜索聊天記錄、可以免打擾。

其實很多中國的產品經理冠著「站在上帝身邊的人」之名，也就是每天在做些個持續改進的事情，修修補補，做完發文字再做發照片、發視頻、髮網址、發投票、發文件。

控制產品節奏感所需要的支持

項目管理

依照傳統的瀑布流方式來做APP的話，先花一周來規劃功能，再花一周來設計界面，然後花上一周來實現功能，最後一周QA測試+改BUG，最理想的情況下也是至少4周一個版本。但實際情況更可能是開發做了一半時產品要改個需求，QA測出一堆問題給開發改結果越改越多，最後一公里大家跑的磕磕絆絆然後受迫於所謂節奏感的deadline把帶著一堆BUG的包發掉，或者就乾脆延期。這樣勢必是不行的。

如果依照敏捷方式來推動項目，情況會完全不同。首先可以將每1周或每2周定做一個Sprint，將需求切分成合適顆粒度的story，然後在每個Sprint內設定好合適的工作量，團隊里各個角色高效協作、並行驅動，就可以確保在Sprint結束時得到可發布的新版本。這樣的話，3~6周的對外版本發布是可以保障的。即便是MIUI這樣的每1周做一次發布，也完全沒問題。

技術支持

想要穩定地控制產品中的BUG風險，其實是需要相當多的技術力量做保障的，否則很可能代碼里總是會有無窮無盡的BUG，代碼隨著產品成長還會越來越複雜，想拿出一個穩定可發布的版本都難。在XP的敏捷實踐里其實是有很多方法來保障代碼穩定的。

TDD 測試驅動開發

TDD會要求開發在寫代碼之前先仔細分析好需求，想好要實現的這部分功能對應的測試場景有哪些，然後基於此來先寫好單元測試，再來寫實現。這樣做的好處是有了這些單元測試的保護，代碼始終是健壯的。即便以後代碼變得複雜，或者要重構修改代碼，只要單元測試跑不過時不要check-in代碼，就不會引入BUG。

CI 持續集成

在每個開發的單元測試都能跑過的基礎上，我們可以用CI來監控整體的代碼。只要有Dev搞掛了CI，技術lead就可以打他屁股了。由於CI是完全自動化地在實時run測試，所以只要任何人check-in的新代碼有問題，就可以及時查出來，這樣就可以避免Bug引入並積壓，讓我們隨時都有可用的版本。那每個Sprint結束時給一個穩定可用的版本還不是小意思。

想要有節奏地規劃產品，揮斥方遒，其實挺不容易的呢，嗯哼~

----------------------
插播一下廣告，ThougtWorks招募UX設計師，坐標深圳、武漢、西安、北京。如果你對中國實體經濟感興趣，希望做一個更加懂業務的設計師，歡迎投簡歷給我czhu@thoughtworks.com

我將這個問題拆分為兩個問題，第一個是「如何進行產品規劃」，第二個是「如何設定迭代周期」。

如何進行產品規劃？

產品規劃又分為長期規劃和短期規劃，而對於互聯網產品而言，我個人不喜歡長期規劃，一方面是市場變化太快（其實不是市場變化快，而是認知上的變化快，不斷地獲得信息的信息），另一外面就是不管是創業還是做產品，都更像是在進行一場實驗，你自己也沒辦法判定最終的產品形態會是怎樣的。但如果這樣的話，就意味著我們只能像個無頭蒼蠅四處亂竄了嗎？還是船到橋頭自然直？我認為可以通過產品願景和中長期規劃來解決這個問題。產品願景是宏觀的，是模糊的，但它給了你一個大的方向，讓你知道應該去往何處。

產品願景怎麼定？老闆定，當然產品經理也需要有自己的思考，一方面讓自己努力地理解老闆心中的產品願景是什麼，一方面思考自己認為合適的產品願景是什麼。產品經理為什麼要思考產品願景？我個人覺得，如果你要真正願意全身心投入一件事情的話，你必須知道事情的前因後果是什麼。

中長期產品規劃怎麼定？結合產品願景及目前制定的市場戰略來定。創業有時間窗口，做產品也同樣有時間窗口，畢竟現在競品這麼多。首先要思考戰略性的業務和功能是什麼，這些功能需要在什麼時候上線，然後排個序。剩餘的時間再排上其它的基於用戶需求和運營需求推導出來的業務和功能。中長期規劃不是一次就能敲定的事情，它是需要定期回顧和調整的。在日常的工作中，產品經理需要持續監控相關的行業新聞及競爭對手的動態，多問問 5 個 w 和 1 個 h，據此判定是否需要調整中長期計劃。

至於短期的產品規劃，則是在給定的設計及開發資源下梳理已有需求的優先順序了。已有的需求包含兩部分，一部分是對已有功能的體驗進行改善（往往來自於用戶反饋，推薦閱讀《啟示錄》，我的讀書筆記），另一部分是新功能的開發。一般情況下，戰略性新功能的開發是最重要的，支撐運營和延伸需求的新功能的開發及對已有功能的優化則需要視情況判定優先順序。產品經理做的一切歸根到底是為運營服務的，但一些已有的糟糕的體驗同樣也會影響運營數據。

如何設定迭代周期？

這裡已經說了是如何設定迭代「周期」，所以表明我認為產品的迭代最好還是有個固定的周期的，當然在特殊情況下允許被打破。對於移動應用的迭代周期，我認為兩到三周是比較合適的。第一，滿足最小化可用原型的原則；第二，對於大部分需求而言，兩到三周的開發時間是可以滿足的；第三，冗長的迭代周期打擊團隊的士氣，人本能上都是渴望儘早看到成果的；第四，多次、小型的合作任務能讓團隊的協作氛圍變得更好；第五，迭代周期太長，導致的產品改動過大會對用戶產生認知的壓力；第六，可以爭取多一些應用商店首發的機會，以及更新頻次也是某些應用商店排名的權重因素之一。

以上的討論不適用於太大太重的產品或功能。

產品迭代的節奏感是非常重要的。

這裡可能存在一些誤解，節奏感我認為不是說要非常清楚未來每個版本該做什麼，以及未來每一步的意圖，正如蘇傑老師所說，這是不現實的，即使有人說有，也更多是事後諸葛亮。

但是產品迭代的節奏感是的確存在的，並且很重要。

舉個例子。

最典型的MIUI的一周一迭代。一個每周更新的緊湊節奏感，帶給開發團隊，內測用戶和外界非常棒的感覺，各個方面如進化速度，用戶預期，內測者成就感和開發效率都因而大大提升。這就是典型的節奏感掌握得好。多提一句，MIUI當時的團隊我覺得是不可能預測到幾個月以後會做什麼功能的（除非戰略規劃），但這個節奏感並不矛盾。

如何實現產品迭代的節奏感？

我個人對迭代節奏感有這樣的思考：

1，通過穩定的大致固定的迭代周期（且比較快），強化整個團隊的意識，如非特殊情況，提需求做設計做需求相對錯開。

2，保證每個迭代周期不是為了做個版本而做，每個周期要有切實有用有價值的功能。的確，許多時候我們不知道如何去考慮未來的功能，但是下一個迭代的需求是可以考慮的（因為往往此前已有許多需求在等待排期了）。這需要考慮開發時間和需求優先順序和需求的意義，具體方法更多需要實例來說。

3，確保每一個迭代周期對用戶預期的滿足。許多產品的迭代周期控制得不錯，但是經常很多版本的更新對用戶毫無意義，不是修復體驗若干，就是帶來什麼商家主頁優化，這些用戶不在乎。每個版本都要給用戶帶來一些新奇，有趣，有價值的功能，確保用戶感知得到你的迭代，和你的節奏感，這樣，用戶會和你們一起來控制和把握，甚至推動這個節奏感。這一點MIUI和微信都做得特別好，可以多參考下。

以上。

節奏感不重要，產品關注結果而不是過程。

產品把握版本迭代應該做到：大版本做減法，小版本做加法；大版本沖亮點，小版本補細節；大版本假設，小版本求證。

如果說這裡最需要拿捏到位的，就是減法做到位，那做到什麼程度算到位呢？就是你做下一個小版本的時候，是不是能從大版本的數據里看出來，很清楚應該朝著你假設里的那個方向走。

其實能不能拿捏好也不重要，最重要你知道這個產品最理想的終極狀態是什麼，走過去的路徑是什麼，需求梳理清晰，從用戶情境中來，回歸到人性中去，做的足夠自然。

產品節奏感分兩部分：

1部分是戰略節奏感，第2部分是項目節奏感。

關於項目節奏感，上面提到的miui是很好的例子。一周一迭代，拉動整個項目組的進度，讓整個團隊在持續改進中。

另外談談戰略節奏感。

一個團隊有應用開發、設計、交互、測試、前端、運營，甚至還有運維等。

除了項目之外，每個職能者都想干一些夯實基礎和框架的事情。那麼這些事情究竟在何時落實？

這些加強基礎建設，還歷史債務的工作，和目前業務優先順序如何排布？

這考驗的是真正的產品戰略節奏感。

如果你作為一方業務的負責人，除了拉動項目節奏外，當項目停歇時就不知道如何是好了，那才是最大的問題。這也是大部分創業公司常常經歷的平台期和迷茫期。

這個時候，普通的產品經理，會定一堆指標，點擊率啊、轉化率啊、註冊數啊等等等等

但優秀的產品經理會知道一個唯一（可能誇張了一點）的核心指標，除了這個核心指標之外的指標，各職能團隊可以自由定義。當這個核心指標達成或未如期達成時，就到達平台期。優秀的產品經理會知道，要定下一個唯一的核心指標，突破平台期。

所謂戰略節奏感，就是時刻知道一個又一個階段的唯一核心指標；這時產生的節奏感，就是你基本感受不到平台期。

好的節奏感確實很重要：

團隊：對產品團隊來說就是知道什麼時候做什麼事，不會出現混亂，提高團隊的開發效率；這個參照一些dota大神的比賽就知道了，良好的farm、gank節奏才能產生滾雪球效應

產品：好的迭代節奏能夠更好的幫助產品進行功能層面上的試錯、探索和布局，更明確的找出適合產品發展的方向。很多產品功能是有明確的父子層級關係，確定優先順序和版本計劃需要很好的節奏把控（微信的版本迭代很能說明這一點，逐步的完善自己產品的功能布局。不過很多遊戲的版本迭代表現更明顯，例如D3）；

用戶：增加產品曝光率、吸引用戶關注和提高用戶黏度。很多沒有什麼要更新的app也要來個周更就是要曝光度和用戶關注。這方面更多的是要考慮你的產品特性和目標用戶的特點，來確定迭代頻率。

留坑再填

一般節奏我是沒有遇到過，各種資源不足，哪兒有安排好了讓你節奏的……

還是要看用戶需求和自身資源情況。

節奏感是事後總結出來的吧？

很多產品1.0的時候知道1.1要做什麼，1.2大概要做什麼，2.0還只是休息的時候yy著玩的呢

真的提前規劃好節奏感的，那一定是未來穿越回來的

能不能做出節奏感不一定，但在功能規劃這事上是有規律可循的。先說幾個主要的參考觀點：

盡量定期發布
每個迭代一個主基調，不能多
動態維護功能List
少而精才是真敏捷

所謂的節奏其實包含了兩方面的含義：外部節奏，內部節奏，外部節奏就是用戶從發布功能產生的感性認知，內部節奏就是內部用怎樣的研發機制來保證外部節奏。

大家應該已經看出來了，外部對應的就是需求實現的優先順序排定，這裡題主特意強調了根據用戶/市場環境做成改變。其實大家都說互聯網產品今天看不到明天，但是大部分團隊一定還是會做半年/一個月/兩周/一周的計劃的，也就是說這個功能的節奏由兩部分來保證的：計劃序列的排定列表，臨時產生的功能計劃，臨時的是用來應對用戶反饋或市場變化的。那麼在一定的迭代周期內確定：「每個迭代一定要有一個主題基調，而且不能太多」前提的情況下，使用插空法順序來產生迭代List，這個List內部是完全有可能保證最終的外部輸出是有節奏的。有興趣你也可以畫一張迭代時間/資源並行分布圖出來試試。

除了蘋果、微信外，之前了解到的有兩個例子可以參考：

1. MIUI的橙色星期五，也就是每周五定期發布更新。

並行模式、全產品周期參與
MIUI開發版每周五發布，小米公司把這一天定義為「橙色星期五」：小米的品牌基調色彩是橙色，每周五下午5點，MIUI正式升級。在小米論壇上，用戶可以決定產品的創新方向或者功能的增減，小米公司為此設立了「爆米花獎」：下一周的周二，小米會根據用戶對新功能的投票產生上周做的最好的項目，然後給員工獎勵，頒發「爆米花獎」。眾多米粉參與討論產品功能，以在下一個版本中做改進。這種將員工獎懲直接與用戶體驗與反饋掛鉤的完整體系，確保員工的所有驅動不是基於大項目組或者老闆的個人愛好，而是用戶的反饋。
http://tech.ifeng.com/internet/detail_2013_11/18/31332435_0.shtml

2. 豌豆莢Polish Week

在豌豆曆法中，每四周的正常工作過後，都會迎來為期一周的 Polish Week。在 Polish Week 中，豌豆們並不會急著寫新的功能、設計新的界面，而是會回顧現有的產品細節，看看在哪些地方還有改進的可能。有時候是挑出一個簡單的錯別字，有時候是差了一個像素沒有對齊的圖標，有的時候則是重構一整個引擎……豌豆們管這個過程叫做「查漏補缺」，也致力於將「查漏補缺」變成 Polish Week 的固定節目。因為我們相信，一個好的產品，只有經過不斷打磨、在細節上呈現出精緻和完美之後，才能稱之為「作品」。
http://www.wandoujia.com/blog/polish-week-201305

內部節奏涉及到大量項目迭代管理的東西，不在這裡贅述，只說一個最基本的觀點：少而精才是真敏捷。少而精對於快速迭代和快節奏的周期保證是至關重要的。

大量的團隊因為對敏捷的偏面認識，快的同時又不注意功能點的減法取捨，上線了大量平庸粗糙的東西。按照目的導向來看，既然迭代的目的是讓用戶對產品更加滿意，更有粘性和活躍，那就應該牢牢以上邊說到的功能List來進行節奏調節，因為這個List本身已經控制了重點功能的收斂，所以即時再敏捷，也能保證重點功能的品質。只有這樣，節奏出來的東西才能獲得好評，而不是做的越多產品越積重難返。

剛開始做產品的時候一直有「偽」大神跟我強調「小吳啊做事做產品要講究節奏，要培養節奏感」。

當時一直搞不懂什麼叫節奏，什麼感覺叫節奏感。做了2年的產品，今天遇到這個問題又重新的思考了一下。

1、節奏感的來源

節奏是需要需求推動的，如果沒有需求，哪裡來的迭代？需求的來源又有很多比如：運營、客服、身邊的朋友、真是用戶、當然還有PM自己悟出來的。當這些需求匯總之後，就會形成自己的change list .

2、節奏感的把握

有了要迭代的內容，需要進行優先順序的區分，一方面是需求價值，另一方面是可分配的資源。能做到平衡就不易，將需求產品化後，剩下輔助設計獅與程序猿進行產品開發。

3、節奏的循環

無論是新產品的開發還是產品從1.0的迭代，開始周而復始的循環，這個節奏的秘訣就是：「咚次打次，咚次打次」。

當然有能力規劃有效的產品半年的roadmap是大神級的PM的工作。大多數能準確的規劃3個月內就不錯了。

我一般只做半年的計劃，且每個季度和能做主的人過Todo list。需求多半來自用戶以及能做主的那個人。另外，我是個節奏感很差，從來不唱K的PM

先做性價比最高的。

我相信聽過張小龍說的：「1.0版本不要做2.0的事」的人不少，能做到的人不多。

因為一個產品經理做版本決策時需要考慮的問題太多了：

1：需求池裡的功能本身的重要程度（用戶使用的頻次、範圍）、緊急程度是什麼？

2：配合推廣的功能你做不做？

3、老大提出的功能要不要做？

4、是做新功能還是改善體驗的細節？

5、已發現的bug要不要改？

最關鍵是，你要一直考慮「老大的耐心——老大覺得這個項目不要繼續做了離現在有多遠」。

可以看看《失控》這本書，凱文凱利所著作，一本巨著。

事實上，你所提到的，節奏感云云，本身並不存在。產品的開始，基本都是源於一些「偽需求」。之所以說偽需求，要麼是公司老闆提名做個產品，要麼是創業團隊幾個人有個好的idea，等等等等，實事求是的講，都不過是只能稱為創意罷了，遠的說，國外如微軟Windows，蘋果一型電腦，Google服務，國內如百度，新浪，騰訊，最早的產品創意無不源自倆字：點子，三字：好點子。當然，所謂的好點子也需要打雙引號，為什麼？彼時，對這些產品的主導者而言，能否成功，還只是個未知數，坊間流傳百度的一個傳聞便是：搜索引擎搭起來了，用戶來了，怎麼盈利，李彥宏還摸不到頭腦，最後還是靠著他老婆排隊買東西，才想到了競價排名，這個臭名昭著的方案，才成就了今日的帝國。當然，傳聞，聽著一樂便可，不過管窺一斑，可見產品的誕生到雄霸一方，並沒有什麼規律，方法論可言。

書歸正傳，推薦這本《失控》，是有目的的，不然微信之父也不會面試的時候聽聞面試者讀過此書就會留人。

且看第三章，有心智的機器。3.2節中提到，自底向上的控制，「當某個系統能夠正常運轉時，不要擾亂它；要以它為基層來構建。在自然體系中，改良就是在現存的調試好的系統上打補丁。原先層級繼續運作，甚至不會注意到其上還有新的層級」。

換言之，對產品設計而言，無規律可循。我們唯一能做的，就是小範圍嘗試，定量數據樣本測試反饋，滿足當前需要後，在其上繼續構建新的業務架構。這一切只能靠摸索著來，曲折中前進。

產品這條路沒有神，只有不斷揣摩用戶，日光之下無新事，不要迷戀於把握節奏，探究技巧方法。新浪微博的案例現成的，騰訊照貓畫虎還做了大量的創新，最後還是失敗了，由此可見，思維，是思維，限制了創造。重點不是產品的創造，再渣的產品，遇到了好的運營思路，趕上了必然騰空而起的大潮，任何人，想擋是擋不住的。

回味一下1999年的至今越活越蹦噠的QQ,再想想被掃到歷史角落裡的MSN，或者，你就會豁然省悟。

以上。

"節奏感"聽起來好高大上呀......我從來都是由於各種資源不足需要從需求中排優先順序和砍需求的痛苦感，除非你有充足的資源，否則做產品的都要明白如何利用現有的資源達到最好的效果。

從大的角度來講，要明白自己產品的每一個階段的目標是什麼，試錯、驗證市場、還是已經找到了正確的路線需要去拉新、提高活躍用戶？
從小的角度講，要明白在當前的階段中哪些需求是必要的，哪些是非必要的，哪些實現起來很費勁但是必須做，哪些很快就能做但是做出來可能就是浪費時間。

作為產品經理，最大的痛苦可能就是產品需求的管理，既要廣泛的聽取用戶和小夥伴們對產品的意見，又要不時地應付老闆突如其來的奇思妙想。而這些還只是需求的收集，還有需要評審的，評審中的，評審過了等待開發的，開發完成了的等到測試的等等。此外還有版本的管理，bug的管理等。如果沒有對需求進行很好的管理很有可能造成工作上的疏漏甚至是產品重大功能的缺失，所以對需求的有效管理勢在必行。

第一步，廣泛的收集需求

#截圖來自teamin示例，略有修改，下同

需求的收集不是越多越好，但是在不知道是不是必需的時候全部搜收集過來，從裡面找到符合產品定位和功能需求的也不失為一個方法。把收集到的需求用列表的方式列出來，列的時候可以採用標籤的方式標明需求的來源，方便後期的管理。

第二步，需求分解

在把所有的需求列出來後，需要對收集到的需求進一步進行分解細化，比如常見的註冊登錄功能，用戶可以使用那些工具進行註冊，註冊完成後後可否與第三方賬號綁定，登錄時可以用那些方式進行登錄等這些都是需要產品經理去考慮，而且需求的粒度劃分的越細，對於後期開發的實現難度就越低，換句話說產品更容易做成功。

第三步，需求計劃安排

對收集到的需求進行評審，是否採用，採用的需要在哪個版本里實現，並將評審通過的需求添加到相應的實現產品版本里，沒有通過的放在另一邊。通過評審的需求可以指定不同的執行者來負責這條需求的最終實現，也可以給需求制定截止時間並通過添加標籤的形式來標明需求的重要緊急程度，以示區別。

第四步，需求跟蹤

需求評審通過後，需要技術哥哥去開發實現了，需求的開發進展是怎麼樣的呢，這個可以通過看板的方式來實現。這個流程也是可以自定義的，添加你認為是必須的環節，比如測試驗收，產品驗收環節等。通過這個看板，需求甚至是整個產品的進展一目了然，再也不用為紛繁複雜需求感到頭疼了。

　　如此，節奏感就自然而然建立起來了。

類似scrum,ci,tdd等這些良好的工程實踐都是為效率及質量而存在的，並非為了節奏。所謂節奏感不應成為產品設計的目標，它只是一系列良好的產品設計開發實踐活動的副產品。你團隊中合理運用scrum，自然就形成了節奏感。

1、做用戶最需要的

2、不要讓用戶等太久

3、至於多久迭代一次，看資源配合速度，也看運營是否能跟得上（特指以內容運營為產品主要方向的產品）

在產品設計之初，總會制定排期表，可是在後期的執行的過程中，會發現各種因素，各種資源不足，導致節奏總會同原來的大不同。這種情況，只能及時記錄，以便查閱，當然，也是同各個部門糾結的時候，一種佐證。

我以為「節奏」說的是使用場景.../捂臉跑開旁聽中...