編輯導(dǎo)語(yǔ)：在產(chǎn)品經(jīng)理的日常工作中，往往需要了解和收集許多的用戶(hù)需求，那么，如何將這些需求進(jìn)行分析篩選，然后轉(zhuǎn)化成為一份產(chǎn)品方案呢？本文作者結(jié)合自身的經(jīng)驗(yàn)，從前期準(zhǔn)備、方案設(shè)計(jì)、需求評(píng)審三個(gè)層面，為我們介紹了如何對(duì)需求進(jìn)行產(chǎn)品化設(shè)計(jì)并通過(guò)需求評(píng)審。

在《用戶(hù)體驗(yàn)要素》一書(shū)中說(shuō)到，產(chǎn)品是由戰(zhàn)略層、范圍層、結(jié)構(gòu)層、框架層和表現(xiàn)層這5層組成。

而之前的文章中，給大家介紹了做產(chǎn)品要如何貼近用戶(hù)、如何評(píng)估需求的。即從戰(zhàn)略層和范圍層的角度，去解決問(wèn)題，定義需求。那在需求明確后，我們又該如何將需求轉(zhuǎn)化成產(chǎn)品方案呢？

這篇文章，將從前期準(zhǔn)備、方案設(shè)計(jì)、需求評(píng)審三個(gè)層面，給大家介紹下該如何從結(jié)構(gòu)層，框架層和表現(xiàn)層，對(duì)需求進(jìn)行產(chǎn)品化設(shè)計(jì)，并通過(guò)需求評(píng)審的。

大家如果有需要的話，可以先收藏，后續(xù)設(shè)計(jì)方案時(shí)，再一一核對(duì)參考，保證我們?cè)谠O(shè)計(jì)方案時(shí)，做到不重不漏。

一、前期準(zhǔn)備

1. 明確需求目的

目的，是產(chǎn)品方案的指向標(biāo)。我們通過(guò)各種渠道，獲得需求后，我們首先要明確，做這個(gè)需求的目的是什么，是為了解決什么問(wèn)題，滿足什么需求而出發(fā)的。

因?yàn)?，我們?cè)谛枨螽a(chǎn)品化過(guò)程中，會(huì)產(chǎn)生很多“新點(diǎn)子”。但這些點(diǎn)，是否適合放到產(chǎn)品方案中，就需要我們立足于需求目的，去通盤(pán)考慮，平衡投入產(chǎn)出比，輸出符合預(yù)期的產(chǎn)品方案。

總的來(lái)說(shuō)，需求或版本的目的可分為以下三類(lèi)：

1. 用戶(hù)體驗(yàn)優(yōu)化：已有功能點(diǎn)優(yōu)化、增加操作入口、增加功能等；
2. 提高內(nèi)部效率：增加內(nèi)部平臺(tái)某種能力、給運(yùn)營(yíng)增加推廣渠道、功能組件化開(kāi)發(fā)等；
3. 商業(yè)化：增加會(huì)員模式、增加對(duì)接廣告接口等。

為了保證產(chǎn)品人對(duì)需求有足夠的深入的思考，一個(gè)版本或一個(gè)方案，都只要解決一個(gè)主要問(wèn)題。因此，我們?cè)诙x目的時(shí)，也要盡可能收攏到一個(gè)核心觀點(diǎn)上，讓整個(gè)方案都圍繞目的服務(wù)。

2. 了解需求背景

不論多大的公司，多大的團(tuán)隊(duì)，在產(chǎn)品的發(fā)展階段，資源都是不夠用的。此時(shí)，論證需求必要性，提高需求實(shí)現(xiàn)的優(yōu)先級(jí)，就非常重要。

而了解需求背景，我們首先找到需求第一來(lái)源人，并通過(guò)以下兩點(diǎn)，來(lái)論證需求必要性：

1）數(shù)據(jù)論證

通過(guò)調(diào)查，從數(shù)據(jù)層面，來(lái)論證需求的緊急性和迫切性。

如：用戶(hù)體驗(yàn)優(yōu)化，可以用用戶(hù)投訴量來(lái)論證；內(nèi)部平臺(tái)能力和商業(yè)化需求，可以用上線多久后提升多少收益，或估算投入產(chǎn)出比（ROI）來(lái)論證。

2）競(jìng)品調(diào)研

若市面上有同類(lèi)產(chǎn)品已實(shí)現(xiàn)該需求，這也可以側(cè)面論證需求實(shí)現(xiàn)的必要性。所以，我們可以通過(guò)調(diào)研的方式，梳理的功能流程圖，并從用戶(hù)、需求、場(chǎng)景三要素進(jìn)行分析，看競(jìng)品是否滿足需求的，又是如何滿足需求的；

但在實(shí)際工作中，系統(tǒng)的競(jìng)品調(diào)研，其實(shí)比較少做，主要是比較耗費(fèi)人力，后續(xù)有機(jī)會(huì)的話，會(huì)專(zhuān)門(mén)寫(xiě)一篇文章來(lái)給大家詳細(xì)介紹，這里就不過(guò)多描述了。

可雖說(shuō)我們比較少做系統(tǒng)的調(diào)研，但我們?cè)谄綍r(shí)的工作中，也會(huì)關(guān)注競(jìng)品每個(gè)版本新增的功能模塊。分析后，若發(fā)現(xiàn)競(jìng)品的新功能是符合用戶(hù)需求的，我們也要及時(shí)跟上。

二、方案設(shè)計(jì)

在明確目的，了解背景后，我們進(jìn)入產(chǎn)品方案的設(shè)計(jì)環(huán)節(jié)了。即下列內(nèi)容，將正式從結(jié)構(gòu)層，框架層和表現(xiàn)層的角度，和大家介紹該如何把需求，進(jìn)行產(chǎn)品化方案呈現(xiàn)的。

而這個(gè)環(huán)節(jié)的最終目的，是要我們輸出完整產(chǎn)品方案，接下來(lái)我將從五個(gè)步驟來(lái)跟大家進(jìn)一步介紹：

1. 邏輯梳理

在做需求時(shí)，很多剛?cè)胄械漠a(chǎn)品，接到需求后，就直接就開(kāi)始畫(huà)原型，這個(gè)是錯(cuò)誤的。因?yàn)?，?huà)原型，是產(chǎn)品方案已經(jīng)確定，產(chǎn)品流程無(wú)明顯紕漏，需求邊界已經(jīng)明確后，才開(kāi)始執(zhí)行的工作。

否則，后續(xù)評(píng)審或開(kāi)發(fā)過(guò)程中，會(huì)出現(xiàn)因方案不夠嚴(yán)謹(jǐn)，出現(xiàn)多次返工的情況。不僅降低我們自己的工作效率之外，而且還可能影響產(chǎn)品的迭代節(jié)奏。

所以，在畫(huà)原型之前，首先我們要先梳理兩個(gè)核心邏輯：

1）產(chǎn)品方案邏輯

產(chǎn)品方案之所以被稱(chēng)之為“方案”，因?yàn)樗菑暮暧^的系統(tǒng)角度，可持續(xù)迭代的層面切入需求，且通常需要多角色配合的。

如，為了減少用戶(hù)投訴而做的產(chǎn)品方案，就要從客服、用戶(hù)、運(yùn)營(yíng)、產(chǎn)品這四個(gè)層面，告知各方在不同的版本后，需要支持和協(xié)助的工作是什么。

因此，我們?cè)谑崂懋a(chǎn)品方案時(shí)，要關(guān)注不同角色的所面臨的問(wèn)題，如何持續(xù)觀察優(yōu)化的角度去通盤(pán)思考。

我們可以從第一用戶(hù)要執(zhí)行的動(dòng)作入手，進(jìn)行邏輯推演。如下圖泳道圖所示，我們?nèi)绻_(kāi)發(fā)一個(gè)給客戶(hù)提供線上下單的平臺(tái)，就可以從要發(fā)貨的客戶(hù)下單的動(dòng)作入手。

客戶(hù)下單之后，訂單數(shù)據(jù)應(yīng)該被哪個(gè)下游角色所接收，接收之后，下游角色還需要哪些角色配合支持，以此來(lái)不斷往下延伸拓展。

在梳理清楚之后，我們?cè)僮罱K把所有角色的交匯場(chǎng)景通過(guò)泳道圖的樣式呈現(xiàn)出來(lái)，明確各個(gè)角色要支持整個(gè)產(chǎn)品方案的具體工作，最終輸出產(chǎn)品方案的流程圖。

2）頁(yè)面流程

頁(yè)面流程是從微觀產(chǎn)品功能層面的邏輯梳理，是包含在產(chǎn)品方案中的某個(gè)產(chǎn)品能力。常用于大小功能點(diǎn)優(yōu)化，版本升級(jí)中某功能點(diǎn)的梳理。

如：上面的客戶(hù)下單、受理、創(chuàng)建單的場(chǎng)景，客戶(hù)是如何在什么頁(yè)面，點(diǎn)擊哪個(gè)模塊下單的，受理部門(mén)受理之后，又是如何創(chuàng)建運(yùn)單的，把這些頁(yè)面的具體操作流程一一細(xì)化梳理出來(lái)。

如果是功能點(diǎn)優(yōu)化，可以從用戶(hù)和數(shù)據(jù)交匯核心頁(yè)面出發(fā)，梳理頁(yè)面流程。

如果是獨(dú)立的功能或產(chǎn)品版本，可以先從功能入口出發(fā)，思考各頁(yè)面中用戶(hù)是誰(shuí)、解決的需求點(diǎn)是什么、產(chǎn)品如何解決需求的，并且后續(xù)還要考慮數(shù)據(jù)流轉(zhuǎn)情況。

這里的用戶(hù)是包括所有使用產(chǎn)品的角色，可能有運(yùn)營(yíng)、客服、銷(xiāo)售、領(lǐng)導(dǎo)層、運(yùn)營(yíng)、開(kāi)發(fā)等。當(dāng)然，如果需要呈現(xiàn)多角色的使用流程，同樣可以利用泳道圖的方式來(lái)呈現(xiàn)。

如果競(jìng)品有類(lèi)似的功能，我們也可以參考競(jìng)品的頁(yè)面流程，但注意，我這里說(shuō)的是“參考”，不是“照抄”。產(chǎn)品人要以滿足用戶(hù)的需求來(lái)思考方案，面向用戶(hù)場(chǎng)景來(lái)設(shè)計(jì)需求，解決用戶(hù)問(wèn)題為最終目的。

3）注意事項(xiàng)

（1）工具無(wú)優(yōu)劣

就跟吃飯用筷子還是用勺子的一樣，選擇適合自己的就行。因此，不論是泳道圖、流程圖、還是簡(jiǎn)單的線框圖，只能能清晰地描述邏輯即可。

（2）方案多選擇

在思考方案時(shí)，肯定會(huì)有多個(gè)方案，多種場(chǎng)景，如果出現(xiàn)難以判斷孰優(yōu)孰劣，可以輸出多個(gè)方案。在內(nèi)部討論或向上匯報(bào)時(shí)，陳述不同方案的優(yōu)劣勢(shì)，讓大家一起討論決策。

以免出現(xiàn)單方案不通過(guò)，要重新思考，降低工作效率。

（3）善于求助

工作是要解決問(wèn)題的，不是來(lái)體現(xiàn)你個(gè)人能力的，這也是你們之所以稱(chēng)之為“團(tuán)隊(duì)”的原因。如果遇到自己確實(shí)無(wú)法解決的問(wèn)題，要及時(shí)向同事或上級(jí)同步困難，尋求幫助。

（4）流程多討論

在方案梳理時(shí)，要和需求涉及的團(tuán)隊(duì)多溝通，尤其是開(kāi)發(fā)，保證方案切實(shí)、可行；在梳理完成后，要盡快在團(tuán)隊(duì)內(nèi)部和領(lǐng)導(dǎo)過(guò)一遍，以保證產(chǎn)品邏輯無(wú)太大紕漏再執(zhí)行下一步。

千萬(wàn)別偷懶，也別怕麻煩，畢竟，很少有人能夠獨(dú)立的把整個(gè)方案都思考得很全面。前期的每一步繁瑣，都是為了避免落地時(shí)的返工。

2. 確定邊界

在確定核心流程之后，需要進(jìn)一步細(xì)化方案，確定需求邊界。主要是補(bǔ)全流程中異常情況和應(yīng)對(duì)策略，盡可能做到，既節(jié)約資源，又擁有好的用戶(hù)體驗(yàn)。

在補(bǔ)全異常流程時(shí)，我們主要關(guān)注四個(gè)問(wèn)題：

1）平衡：注意平衡用戶(hù)體驗(yàn)與開(kāi)發(fā)工作量的關(guān)系

在實(shí)際工作中，工作量和用戶(hù)體驗(yàn)是成反比的，體驗(yàn)越好的模塊，工作量越大。所以，產(chǎn)品的工作要從需求目的出發(fā)，尋找雙方的平衡。該如何取舍，取決于產(chǎn)品發(fā)展情況、市場(chǎng)情況、產(chǎn)生命周期和產(chǎn)品自己的工作經(jīng)驗(yàn)。

如果遇到難以決策或解決的問(wèn)題，要及時(shí)向上匯報(bào)，尋求幫助。

2）安全：資金安全和用戶(hù)安全問(wèn)題

新版本的微信，紅包功能就調(diào)整了紅包個(gè)數(shù)和金額的位置，導(dǎo)致有大量的用戶(hù)導(dǎo)致資金和金錢(qián)輸入錯(cuò)誤，導(dǎo)致用戶(hù)投訴。

因此，如果需求涉及資金、用戶(hù)信息等問(wèn)題，要慎之又慎。產(chǎn)品文檔在進(jìn)入評(píng)審會(huì)之前，最好多過(guò)幾輪，以求萬(wàn)無(wú)一失。

3）復(fù)用：組件化開(kāi)發(fā)

如果功能模塊后續(xù)可能被其他需求所復(fù)用，為節(jié)約開(kāi)發(fā)成本，可以與研發(fā)多溝通，看是否可進(jìn)行組件化開(kāi)發(fā)。

如：banner廣告可能可以在其他頁(yè)面復(fù)用，但當(dāng)前版本僅支持首頁(yè)的應(yīng)用即可，就可以進(jìn)行組件化開(kāi)發(fā)，后續(xù)其他頁(yè)面如果需要的話，就可以直接復(fù)用。

4）便捷：配置性功能開(kāi)發(fā)

如：banner的內(nèi)容后續(xù)需要經(jīng)常更換，為了減少后續(xù)反復(fù)發(fā)版，影響線上功能，也可以和研發(fā)多溝通，看能否進(jìn)行配置性開(kāi)發(fā)。

這也是節(jié)省了研發(fā)后續(xù)的工作量，你跟他提，他會(huì)比較樂(lè)意幫助你的。

3. 原型設(shè)計(jì)

原型設(shè)計(jì)是在框架層，來(lái)思考和設(shè)計(jì)產(chǎn)品的。前面的邏輯和需求邊界都確定的話，這一步其實(shí)可以讓交互設(shè)計(jì)師來(lái)支持，尤其是業(yè)務(wù)推進(jìn)比較忙的時(shí)候。

但并非所有公司都有交互設(shè)計(jì)師，如果沒(méi)有的話，這一步還需要自己來(lái)實(shí)現(xiàn)。畫(huà)原型的具體操作，就不多講了，如果是剛?cè)胄谢驕?zhǔn)備入行的小伙伴，想學(xué)的話，可以報(bào)個(gè)班學(xué)一下Axure或sketch。

不用太精通，只要能把想要的頁(yè)面，簡(jiǎn)單的還原出來(lái)，設(shè)計(jì)師和開(kāi)發(fā)都能看懂，就已經(jīng)足夠了。在這里我講一下幾個(gè)避坑指南：

1）原型分版本保存

我剛做產(chǎn)品的時(shí)候，原型都是直接覆蓋上一個(gè)版本的。但后來(lái)，評(píng)審會(huì)的時(shí)候老大提出要加什么功能，我突然想起這個(gè)功能在之前一個(gè)版本做過(guò)，但想找回來(lái)，卻發(fā)現(xiàn)版本已經(jīng)被覆蓋，找不到了…

2）原型有注釋

如果原型沒(méi)注釋?zhuān)透险n不做筆記的后果一樣，很容易一轉(zhuǎn)頭就忘了。而且不在原型中注釋的稿件，如果給開(kāi)發(fā)或設(shè)計(jì)執(zhí)行時(shí)出錯(cuò)了，最后吃虧的還是我們自己。

3）異常情況定義清楚

除正常的注釋之外，異常情況也需要在原型中定義清楚。

因?yàn)?，有些開(kāi)發(fā)在開(kāi)發(fā)時(shí)，不一定會(huì)時(shí)刻盯緊文檔來(lái)看。所以，除了文檔中要說(shuō)清楚異常情況的設(shè)計(jì)標(biāo)準(zhǔn)之外，最好在原型中也要注釋清楚，也是為了避免后面出現(xiàn)問(wèn)題時(shí)，相互扯皮。

4）需求修改及時(shí)備注

如果需求在評(píng)審或開(kāi)發(fā)過(guò)程中，有變更的情況，除了在文檔中備注之外，原型中也需要及時(shí)變更。

以上內(nèi)容，都是我用血和淚給大家總結(jié)的經(jīng)驗(yàn)教訓(xùn)，我剛?cè)胄械臅r(shí)候，因?yàn)橥祽?，很多地方?jīng)]有做好，當(dāng)時(shí)背過(guò)很多鍋，所以希望大家，千萬(wàn)不要再重蹈我的覆轍了。

4. 建立數(shù)據(jù)反饋

一個(gè)好產(chǎn)品人，是會(huì)從更高的產(chǎn)品系統(tǒng)的層面，思考和解決問(wèn)題的。

因此，為了更好地驗(yàn)證目標(biāo)的達(dá)成與否，我們需要建立數(shù)據(jù)反饋機(jī)制，給產(chǎn)品方案提供統(tǒng)一的衡量標(biāo)尺。我們團(tuán)隊(duì)建立數(shù)據(jù)反饋主要是通過(guò)兩點(diǎn)：

1）埋點(diǎn)

C端的功能型需求，是可以通過(guò)用戶(hù)反饋來(lái)迭代的。但除此之外，我們還要增加當(dāng)前功能點(diǎn)的埋點(diǎn)，為產(chǎn)品后續(xù)優(yōu)化提供更嚴(yán)謹(jǐn)?shù)睦碚撝С帧?/p>

如果是剛上線的基礎(chǔ)功能，還未確定明確的業(yè)務(wù)指標(biāo)，可以只增加基礎(chǔ)埋點(diǎn)。如：產(chǎn)品頁(yè)面曝光pv、曝光uv、點(diǎn)擊pv、點(diǎn)擊uv等。

將埋點(diǎn)數(shù)據(jù)統(tǒng)一上報(bào)到數(shù)據(jù)平臺(tái)中，定期觀測(cè)數(shù)據(jù)表現(xiàn)情況，以便優(yōu)化后續(xù)產(chǎn)品。但如果是有上線有一段時(shí)間的產(chǎn)品，我們要從業(yè)務(wù)指標(biāo)衡量標(biāo)準(zhǔn)出發(fā)，對(duì)產(chǎn)品數(shù)據(jù)埋點(diǎn)，進(jìn)行二次或三次的拆解。

也可以參考前面的頁(yè)面流程圖，一般來(lái)說(shuō)，有需要判斷的地方就要有埋點(diǎn)。我們只有知道每個(gè)節(jié)點(diǎn)數(shù)據(jù)流向，后續(xù)才能建立數(shù)據(jù)模型，分析用戶(hù)操作。

2）異常監(jiān)控

產(chǎn)品要經(jīng)常主動(dòng)觀察數(shù)據(jù)表現(xiàn)，但人力有限，我們無(wú)法做到24小時(shí)實(shí)時(shí)盯著數(shù)據(jù)。所以，若功能中有影響用戶(hù)核心操作的功能點(diǎn)，還需要讓研發(fā)幫忙建立異常監(jiān)控，以保證產(chǎn)品核心流程能夠滿足用戶(hù)正常使用。

如：我們團(tuán)隊(duì)就有通過(guò)微信的開(kāi)放能力，建立告警機(jī)制，一旦某個(gè)商家出現(xiàn)問(wèn)題，就會(huì)出現(xiàn)如下圖所示的告警通知，以便我們的產(chǎn)品和開(kāi)發(fā)團(tuán)隊(duì)能快速發(fā)現(xiàn)并處理問(wèn)題

這也是技術(shù)團(tuán)隊(duì)在溝通方案時(shí)，要和技術(shù)一同關(guān)注的風(fēng)險(xiǎn)點(diǎn)。

5. 需求文檔

在全面思考以上的四點(diǎn)后，我才會(huì)遵循以下呈現(xiàn)方式，將它們統(tǒng)一收攏到文檔中，形成完整的產(chǎn)品方案。

首先，在文檔開(kāi)頭，描述背景和目的，最好用調(diào)查過(guò)的數(shù)據(jù)，來(lái)論證需求實(shí)現(xiàn)的必要性；其次，將產(chǎn)品原型或交互設(shè)計(jì)稿放到需求模塊，要圖文結(jié)合，讓文檔的閱讀者能夠清晰地知道每個(gè)功能點(diǎn)，具體需要做什么。

如果涉及多端支持的需求，我會(huì)從支持端的角度來(lái)陳述需求。即前端要做什么，后臺(tái)要做什么，數(shù)據(jù)要做什么，支付要做什么。

然后，把接口文檔、原型、交互稿、設(shè)計(jì)稿等相關(guān)附件，都附在需求文檔中，以免遺失；最后，再補(bǔ)充一點(diǎn)，如果文檔有變更，要及時(shí)，立刻更新到文檔中，同步給各方，避免背鍋。

我的習(xí)慣是在開(kāi)頭用紅色加粗字體，描述修改的需求點(diǎn)和修改日期。

三、需求評(píng)審

當(dāng)完成上面所有內(nèi)容后，我們的需求才可以進(jìn)入到需求評(píng)審階段。需求評(píng)審的目的，是為了論證需求執(zhí)行的必要性，方案落地的可行性，同時(shí)給要支持需求的各方，都能夠了解產(chǎn)品方案具體需要大家做什么。

所以，為了讓產(chǎn)品需求順利通過(guò)評(píng)審，我們要從評(píng)審目的出發(fā)，逐一打消評(píng)審方的疑慮。

1. 需求必要性評(píng)估

評(píng)審一開(kāi)始，就要先陳述目的和背景。這里前面也講過(guò)，要用數(shù)據(jù)來(lái)論證需求必要性，調(diào)查的數(shù)據(jù)必須要足夠合理且嚴(yán)謹(jǐn)，才能有效通過(guò)評(píng)審，并拔高需求優(yōu)先級(jí)。

2. 方案可行性評(píng)估

介紹完目的和背景，獲得評(píng)審各方的認(rèn)可之后，就可以和大家介紹解決問(wèn)題的需求方案，和數(shù)據(jù)埋點(diǎn)情況。

在陳述方案環(huán)節(jié)，我也遇到過(guò)需求被直接打回的。出現(xiàn)這種問(wèn)題，可能是前期產(chǎn)品邏輯有問(wèn)題，又或者是產(chǎn)品方案沒(méi)有和開(kāi)發(fā)充分溝通，最終設(shè)計(jì)出不適合落地需求。

但一般能到評(píng)審會(huì)的需求方案，都通過(guò)了產(chǎn)品內(nèi)部的評(píng)估，基本沒(méi)什么方向和邏輯上的問(wèn)題，除非是自己偷懶。而技術(shù)層面能否通過(guò)評(píng)審，就依賴(lài)于我們?cè)谇捌谠O(shè)計(jì)方案的時(shí)候，是否能多和開(kāi)發(fā)溝通，明確技術(shù)細(xì)節(jié)，以保證方案是可以落地的。

3. 方案持續(xù)性介紹

一般前兩點(diǎn)評(píng)估通過(guò)，需求就是可以落地執(zhí)行的了。但我在介紹完方案之后，還會(huì)補(bǔ)充介紹下后續(xù)的運(yùn)營(yíng)方案和產(chǎn)品的迭代計(jì)劃。

一來(lái)，可以給開(kāi)發(fā)打個(gè)預(yù)防針，告知這個(gè)功能后續(xù)優(yōu)化的可能性，讓他們提高對(duì)需求的重視程度；二來(lái)，系統(tǒng)全局的描述，也能體現(xiàn)你在產(chǎn)品能力。

每一個(gè)產(chǎn)品需求，都是我們展現(xiàn)自己的機(jī)會(huì)。在職場(chǎng)，只有緊緊抓住每一個(gè)機(jī)會(huì)，我們才有承接更大需求，在產(chǎn)品道路更進(jìn)一步的可能。

三、寫(xiě)在最后

產(chǎn)品方案，是從用戶(hù)、問(wèn)題、場(chǎng)景的視角去切入需求，在更系統(tǒng)的產(chǎn)品層面和更長(zhǎng)的時(shí)間維度上，全面思考，輸出的文檔。

以上內(nèi)容，是我這兩年，把寫(xiě)過(guò)的大大小小數(shù)百個(gè)需求，匯總整理出來(lái)的。包括目的、背景、產(chǎn)品邏輯、需求邊界、原型、數(shù)據(jù)、需求文檔這七點(diǎn)，我將這七點(diǎn)統(tǒng)稱(chēng)為需求落地的“七要素”。

本文由 @豆奶?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash，基于CC0協(xié)議。