產(chǎn)品設(shè)計(jì)規(guī)劃時(shí)經(jīng)常會(huì)面臨諸如“功能完整與拆分迭代，縮短路徑與加層跳轉(zhuǎn)，簡(jiǎn)潔排布與充分利用”之間的矛盾，而這系列矛盾也不是簡(jiǎn)單的非此即彼，相互關(guān)聯(lián)而又相互制衡。

• 拆分迭代更有利于產(chǎn)品驗(yàn)證，而產(chǎn)品的最終目標(biāo)還是演化至趨于完整，只是階段不同，追求完整還不算是一個(gè)最主要的內(nèi)容；

• 減少操作次數(shù)，縮短行為路徑是一個(gè)至關(guān)重要的設(shè)計(jì)理念，但也需要兼顧頁(yè)面內(nèi)容元素，一個(gè)頁(yè)面只傳遞一個(gè)核心信息，一個(gè)頁(yè)面只有一個(gè)視覺(jué)焦點(diǎn)，在秉承這一核心要求的前提下，有時(shí)增多層級(jí)跳轉(zhuǎn)反而是一個(gè)更合理的選擇；

• 頁(yè)面簡(jiǎn)潔不等于簡(jiǎn)單、元素少，而是傳遞信息的直接有效，更需要考慮的是用戶在頁(yè)面所保留的注意力，在保持有高注意力的頁(yè)面一次性展示更多內(nèi)容，更有利于增強(qiáng)產(chǎn)品可用性，提高使用效率。

產(chǎn)品設(shè)計(jì)規(guī)劃時(shí)常就是一個(gè)進(jìn)退兩難，不斷抉擇的復(fù)雜過(guò)程，需要時(shí)刻秉承著追求“樸素”的心態(tài)，適可而止，效用為先。

“如無(wú)必要，勿增實(shí)體”，簡(jiǎn)單有效原理。大多數(shù)情況下我們也都知道要注意保持簡(jiǎn)單易用，而經(jīng)常遇到的是一開始就已經(jīng)將問(wèn)題復(fù)雜化，容易只從充分性的角度來(lái)考慮，導(dǎo)致忽略了需求的必要性，也就很可能導(dǎo)致需求蔓延和鍍金需求的增多。過(guò)于追求“細(xì)枝末節(jié)”，過(guò)于執(zhí)著“用戶體驗(yàn)”，有時(shí)更需要保持“有限理性”，適可而止。確定階段性功能，定義功能方向及階段系統(tǒng)邊界，形成階段性聚焦，適當(dāng)放棄部分現(xiàn)階段暫時(shí)還無(wú)需關(guān)注的內(nèi)容。

1.1 定義最需解決問(wèn)題

用戶所面臨的問(wèn)題大多數(shù)情況下都是多方面的，期待的解決方案也可能是最理想化的，此時(shí)需要尋找出最需解決的問(wèn)題，集中力量資源解決核心問(wèn)題，更高效精準(zhǔn)地取得用戶滿意。如果解決了這個(gè)問(wèn)題，用戶的處境就會(huì)有最大程度的改變，這就是用戶現(xiàn)階段最需解決的問(wèn)題。同時(shí)考慮哪些限制條件會(huì)影響到用戶的流程環(huán)節(jié)過(guò)渡，是否存在可保留的舊體驗(yàn)，從而確定當(dāng)前版本的系統(tǒng)功能邊界。拆分出終級(jí)效果和階段性目標(biāo)，可降低問(wèn)題處理復(fù)雜度。

案例：對(duì)于線下門店優(yōu)惠券派發(fā)線上化，目的是想通過(guò)電子化更便捷地派發(fā)，分析衡量出不同優(yōu)惠券的具體效果，更科學(xué)地實(shí)現(xiàn)降本增效。面對(duì)這一目標(biāo)我們很容易一開始就陷入如何精準(zhǔn)地做出效果評(píng)估，“推送-曝光-查看-使用”等環(huán)節(jié)的流程轉(zhuǎn)化，通過(guò)費(fèi)效比分析得出哪種券類型、券組合表現(xiàn)更優(yōu)，但這在一定程度上只是彌補(bǔ)了線下記錄操作繁瑣，數(shù)據(jù)記錄不全的的缺陷，是在維持原有或改變不大的派發(fā)效果基礎(chǔ)上進(jìn)行的分析，側(cè)重于事后的后見性分析。

容易忽視了推送的前一步，優(yōu)惠券以及推送機(jī)制的設(shè)計(jì)，而線上化帶來(lái)的用戶精細(xì)行為數(shù)據(jù)采集更有利于該方面內(nèi)容的驗(yàn)證，發(fā)掘不同優(yōu)惠券形式對(duì)用戶觸達(dá)和轉(zhuǎn)化的影響，哪些元素更有利于拉新促活，這是在全局推送前需要率先驗(yàn)證的問(wèn)題，包括配圖呈現(xiàn)，文案擬定，產(chǎn)品亮點(diǎn)，推送時(shí)機(jī)等等。精準(zhǔn)的流量以及承接該批流量的產(chǎn)品觸發(fā)點(diǎn)，面對(duì)降本增效這一整體目標(biāo)，在初始階段，提高整體發(fā)放消息的點(diǎn)擊轉(zhuǎn)化率更能達(dá)到增效的目的，而不是在原本還未達(dá)到“最優(yōu)”中強(qiáng)行擇優(yōu)，需要同時(shí)兼顧事前事中事后的全環(huán)節(jié)管理流程。

1.2 尋找最簡(jiǎn)解決方案

在明確了現(xiàn)階段最需解決的問(wèn)題之后，依然會(huì)面臨諸多不確定因素，需實(shí)行最小可行產(chǎn)品形態(tài)推進(jìn)驗(yàn)證，尋找最簡(jiǎn)解決方案，減少投入成本的沉沒(méi)流失，加快產(chǎn)品的落地使用、市場(chǎng)占有。

簡(jiǎn)化產(chǎn)品方案思考框架

1）不做這一步會(huì)有什么后果？

2）如果不這么做都是怎么做？

3）別人沒(méi)按照你的意思去做，反而采用了其他方式，會(huì)有什么效果？

4）如果按照所說(shuō)的去做了，效果不好，大概率是哪個(gè)環(huán)節(jié)出了問(wèn)題？

（借用自《得到品控手冊(cè)7.0》得到主編采訪課程專欄老師完善內(nèi)容質(zhì)量的問(wèn)題技巧框架）

案例：對(duì)于線上商超便利店平臺(tái)初期推廣階段，重點(diǎn)在于驗(yàn)證平臺(tái)是否能擁有預(yù)期用戶流量，需快速招攬店家入駐完成驗(yàn)證。商品上架作為線上開店不可或缺的功能，涉及掃碼識(shí)別、規(guī)格價(jià)格設(shè)置、商品分類管理、商品描述等多個(gè)方面，且不同子模塊間相互關(guān)聯(lián)難以精減，如果初期壓根就沒(méi)有商品上架功能呢？

1）不做這一步會(huì)有什么后果？

店家不可手動(dòng)自主上架商品，全部調(diào)用平臺(tái)商品庫(kù)商品，店家僅可售賣常見商品，非常見非標(biāo)商品暫不支持售賣。店家上架自家特有商品是為能體現(xiàn)出自家商品種類齊全，與周邊商家的差異化，提供配送上門服務(wù)更好服務(wù)于周邊客戶。

    · 對(duì)于前期階段，一定區(qū)域內(nèi)不會(huì)出現(xiàn)太多的試點(diǎn)店家，商品的差異化競(jìng)爭(zhēng)因素可暫不考慮；

    · 盡管商品沒(méi)有上架完全，但對(duì)于以服務(wù)老客為主的零售便利店而言（主要推廣方式以客戶到店后再向其介紹線上訂單服務(wù)），前期客戶如有其它需求，可在訂單中進(jìn)行備注說(shuō)明，盡管會(huì)造成銷售庫(kù)存數(shù)據(jù)不同步，但小需求商品可先由人工校對(duì)調(diào)整。

2）如果不這么做都是怎么做？

平臺(tái)商品庫(kù)商品需要足夠常見，適用于大多數(shù)店鋪，在挑選種子樣板店時(shí)需考慮經(jīng)營(yíng)業(yè)態(tài)、在售商品相似度較大的店鋪，使能夠涵蓋店家的大多數(shù)商品，對(duì)于銷量不大的長(zhǎng)尾商品進(jìn)行適當(dāng)壓縮，對(duì)于存在太多需要計(jì)量的非標(biāo)商品店家可暫不考慮。

3）別人沒(méi)按照你的意思去做，反而采用了其他方式，會(huì)有什么效果？

新平臺(tái)初期為吸引店家，基本都是免費(fèi)邀請(qǐng)或補(bǔ)貼入駐，而對(duì)商家而言是獲得了一個(gè)新的訂單來(lái)源途徑，有勝于無(wú)。重點(diǎn)在于不能有太大的入駐門檻，店家不愿意為一個(gè)不確定的銷售渠道投入太多精力資源。上架商品對(duì)店家而言就是一個(gè)繁瑣的大工程，除非對(duì)平臺(tái)有足夠的引流信任，否則不會(huì)輕易就有商品上架意愿。在前期平臺(tái)還無(wú)法取得店家信任時(shí)，降低門檻就變得至關(guān)重要，從這一方面來(lái)看直接商品庫(kù)上架反而更有利于推廣。

4）如果按照所說(shuō)的去做了，效果不好，大概率是哪個(gè)環(huán)節(jié)出了問(wèn)題？

假設(shè)按照以上做法推進(jìn)，也可能因?yàn)樵摲桨敢鲆恍┬碌膯?wèn)題導(dǎo)致引流轉(zhuǎn)化效果不理想、流量驗(yàn)證不準(zhǔn)確。例如商品品類不夠豐富、商品描述不準(zhǔn)確、采用全平臺(tái)統(tǒng)一但同一商品在不同店家間會(huì)存在質(zhì)量差別等，需要有預(yù)留地進(jìn)行調(diào)研驗(yàn)證。

小結(jié)

尋找最簡(jiǎn)解決方案目的在于以最低成本盡快測(cè)試想法，關(guān)鍵是驗(yàn)證需求是否有普遍性，能否引起用戶共鳴，需要驗(yàn)證的風(fēng)險(xiǎn)是“用戶會(huì)來(lái)我們平臺(tái)上下單嗎”而不是“我們?nèi)绾巫龀鲆粋€(gè)線上下單平臺(tái)”。明確哪些舊體驗(yàn)可以在初代版本中保留，哪些流程操作可以先由人工替代，采用專人接待式服務(wù)模式等。

追求簡(jiǎn)單的另一方面還在于避免因?yàn)槟骋还δ艿耐度攵l(fā)出了其他新的關(guān)聯(lián)需求。做不做一個(gè)功能，除了考慮現(xiàn)在所需花費(fèi)的成本資源，還需要考慮可能激發(fā)出來(lái)的新需求，避免打開“潘多拉魔盒”必須持續(xù)投入資源不停增加。

1.3 兼顧拓展遷移成本

早期系統(tǒng)除了考慮簡(jiǎn)化產(chǎn)品解決方案外，還需要兼顧后續(xù)拓展可能性，可拓展一方面是保持系統(tǒng)底層結(jié)構(gòu)的可復(fù)用，避免重構(gòu)，另一方面是避免由于拓展造成過(guò)大的遷移成本導(dǎo)致用戶流失。

案例：針對(duì)客戶標(biāo)簽體系，前期就需要能夠?qū)?biāo)簽數(shù)量級(jí)有一個(gè)預(yù)估，是否需要一開始就支持創(chuàng)建標(biāo)簽組，前期系統(tǒng)剛投入使用，不支持分組管理對(duì)用戶不會(huì)有太大影響。但到了后期隨著標(biāo)簽數(shù)量的增多，標(biāo)簽管理、查找就會(huì)變得繁瑣，此時(shí)就會(huì)要求對(duì)標(biāo)簽進(jìn)行分組。如果前期未能考慮到該擴(kuò)展的可能性，此時(shí)再增加分組功能，就會(huì)導(dǎo)致整個(gè)標(biāo)簽的數(shù)據(jù)表結(jié)構(gòu)發(fā)生較大變動(dòng)，用戶已創(chuàng)建的標(biāo)簽需手動(dòng)遷移至新創(chuàng)建分組內(nèi)，額外操作的工作量太大會(huì)讓用戶產(chǎn)生抗拒心理，即使很清楚分組后后續(xù)使用會(huì)更加方便，但過(guò)大的操作壓力可能會(huì)導(dǎo)致用戶猶豫不決，最終選擇放棄使用系統(tǒng)。

1.4 分支下鉆延伸迭代

完成核心驗(yàn)證，明晰了產(chǎn)品大體方向，后續(xù)演化迭代就是一個(gè)又一個(gè)“構(gòu)建-衡量-學(xué)習(xí)”循環(huán)的過(guò)程。迭代重點(diǎn)在于只聚焦于核心模塊的下鉆延伸，不致于產(chǎn)品邊界過(guò)于模糊擴(kuò)散導(dǎo)致功能越積越多，但對(duì)產(chǎn)品價(jià)值沒(méi)有太多實(shí)質(zhì)性的提升。

爬山算法，增加高度/值方向上的連續(xù)移動(dòng)，以找到山峰或最佳解決方案的方法。這一模型多運(yùn)用于算法工程，但也同樣適用于產(chǎn)品的迭代思路，分支下鉆、精益求精，而不是去創(chuàng)建更多的分支。通過(guò)一點(diǎn)點(diǎn)改變某個(gè)變量，改動(dòng)之后如果得到更好的解決方案，就再?gòu)倪@一新方案中再選擇一個(gè)變量進(jìn)行小幅改變，不斷反復(fù)，直到解決方案無(wú)法進(jìn)一步優(yōu)化為止。優(yōu)化一個(gè)指標(biāo)獲得的成效越來(lái)越小，就意味著達(dá)到了一個(gè)基準(zhǔn)點(diǎn)，再去優(yōu)化下一個(gè)重要指標(biāo)。

案例：假設(shè)消息推送是某APP訂單轉(zhuǎn)化的重要來(lái)源方式，現(xiàn)通過(guò)驗(yàn)證已經(jīng)得出某一時(shí)間點(diǎn)是一天中的最佳推送時(shí)機(jī)，push點(diǎn)擊率達(dá)到最高。接下來(lái)除了調(diào)整消息推送時(shí)間外，還需要進(jìn)步驗(yàn)證該時(shí)間段內(nèi)高點(diǎn)擊率消息內(nèi)容是否具有一定的相似性，內(nèi)容類型是否有改善的空間；點(diǎn)擊用戶是否具有獨(dú)特的人群化特性或具有相似的用戶行為，激活了非活躍用戶還是持續(xù)觸活了活躍用戶等等。持續(xù)提升改善現(xiàn)有的已證明重要的訂單來(lái)源方式轉(zhuǎn)化效果，而不是嘗試拓展具有高不確定性的新訂單產(chǎn)生途徑，提高做對(duì)事情的概率。

1.5 小結(jié)

不只是產(chǎn)品從0到1要秉承最小可行原則，追求樸素，在任何時(shí)期的迭代落地都要遵從該理念，如無(wú)必要，勿增實(shí)體，保持有限理性，在一個(gè)更小、更容易觸及的目標(biāo)市場(chǎng)、特定場(chǎng)景中持續(xù)培養(yǎng)更多具有黏性的高活躍用戶。