編輯導讀：需求，在互聯網行業工作的每個人都耳熟能詳的詞。不管是在哪個崗位，都會面對五花八門的需求。本文作者根據他在小紅書的工作經曆，總結了自己關于需求的收獲和成長，希望對你有幫助。

本文記錄我在小紅書電商産品部營銷組的主要工作與收獲，三個月實習期間我承接了來自3個模塊的6個需求，每個需求的耗費時間并不長，但我的收獲和成長都比較多。

商家後台的體驗性需求：商家後台服務于自營店鋪和第三方商家，裡面的闆塊衆多，我隻承接來自促銷闆塊的需求，這裡的兩個體驗性需求是我在剛入職時做的，難度不高，主要用于熟悉産品流程，但後來複盤時發現也有較多值得思考與改進的點。

促銷場景的調研與拓展性需求：這個模塊是在制定平台促銷的底層規則、拓展新的促銷場景和營銷工具，由于平台已經有一套較為成熟的規則，并且一次變動帶來的影響範圍較廣，所以這邊的需求沒有太多的叠代，我主要通過調研了解了電商促銷的體系，并支持C端沉澱了一個新的券場景搭建工具。

價格中台的叠代性需求：價格中台主要為小紅書C端各個業務場景提供價格計算能力，有長期業務價值、需求複雜度也較高，但我所承接的需求的實際方案并不複雜，在這個需求中比較困難的點在兩個方面：溝通與協調各個C端業務場景；梳理現存的規則找出不合理性。

一、商家後台的體驗性需求

商家後台主要服務于自營店鋪和第三方商家，後台包含了諸多商家日常管理的模塊，比如店鋪、商品、訂單、物流等，我所在的業務僅承接其中的促銷模塊。我在這部分業務中主要做了兩個需求，一個是驚喜盒子活動報名流程的優化，一個是預售管理的體驗優化。

1. 驚喜盒子活動報名流程優化

1）需求背景

驚喜盒子是小紅書内給用戶發優惠券的場景之一，用戶在逛社區筆記的過程中，會掉落驚喜盒子券，促進用戶從社區轉化到商城購物。這個需求來源于負責收集與審核驚喜盒子券的運營同學，商家每月會提報一定數量的券，整個流程為：

整個流程出現了以下問題：

• 商家提報的券和主圖不符合要求的比例較高，尤其是主圖不合格數量占比80%
• 運營審核不通過後，重新報名比例較低

2）需求分析

分析後發現，出現這兩個問題的原因在于：

• 商家在報名過程中無法感知到運營設定的券和主圖的要求
• 商家無法收到報名審核不通過的通知
• 商家看到審核不通過的列表後找不到重新報名的入口，隻能重新走一遍報名流程

3）需求複盤

需求的背景很清晰，方案也不複雜，在整個需求過程中，我遇到的問題主要集中在評審與開發階段：

• 需求評審時被質疑有實現複雜度更低的方案；
• 評審過程中開發提出當前方案會影響系統中的其他部分，影響商家的判斷；
  • 在通知商家不通過的方案中，我的提示話術是“您有一條活動報名不通過”，這會讓商家誤認為這裡的提示是針對所有類型的活動報名，但我們本次的需求僅針對驚喜盒子類型。
• 開發過程中研發需要相關的提報情況數據，作為開發成本的判斷

通過這個需求遇到的問題給我帶來的思考：

• 業務價值的判斷：這是我前期在做需求時感悟最深的點，需求的實現最終是為了推動業務發展的，因而在接到一個需求前首先需要明确的就是這個業務的價值有多高；
• 提前思考方案的實現複雜度：當前是最優方案嗎？有沒有替代性方案？這個方案與替代性方案相比有什麼優點和不足？這裡的優點是否值得去做更高成本的投入？
• 方案設計時考慮對相關模塊的影響：由于B端的需求之間聯系密切，往往牽一發而動全身，因而去改動系統中一個邏輯時需要更全面的思考它的影響範圍，這裡的影響範圍不僅是其他闆塊，也可能是其他業務方；
• 産品文案打磨：在設計産品的過程中避不開一些文案撰寫，比如功能名稱、提示語、頁面引導語等。

2. 預售管理體驗優化

1）需求背景

預售是電商促銷中非常常見的玩法，用戶通過提前支付定金預定商品，并在尾款期支付尾款完成下單。而在此之前，商家需要在後台提前配置好預售商品，包括商品的預售時間（分為定金期和尾款期）、預售價格（分為定金價格、尾款價格、膨脹價格）等。

在使用過程中，商家遇到了一些體驗問題，并提出了如下需求：

• 可以支持多選預售狀态導出預售數據
• 已終止的預售ID，支持查看詳情
• 商品價格落入“真空價格區間”（報關商品會出現的價格校驗區間）報錯提示更詳細
• 可批量配置定金預售

2）需求分析

以上的四個需求，前三個主要在于新增入口或功能，并無太多方案産出的空間，需要産品推動研發實現，主要集中在最後一個需求，需要考慮批量配置的方式和流程：

• 配置方式：以Excel格式批量上傳
• 表格字段：包含預售必須的商品ID、可售量、預售價、定金金額、膨脹金額
• 配置前：提供模版下載入口
• 配置後：需要提示是否配置成功，若有失敗，應該告知失敗名單和原因

3）需求複盤

處理這個項目遇到的主要問題有：

• 需求被砍：在評審過程中，多選預售狀态的需求實現難度比我們想象的要大很多，加上研發認為當前分幾次導出的工作量并沒有這麼大，因而這個需求被否掉了
• 需求價值被質疑：在開發過程中，批量配置的後端工作量超出預期，需要後端重新寫一套邏輯，花費了3pd去做這件事，導緻研發在此期間一直有問我日常預售商品的配置數量如何
• 上線後發現影響較大的錯誤：在三八大促預售配置當晚，自營運營同學發現定金校驗的規則是不完全的，實際校驗規則比我最初制定的要更複雜

為我帶來的思考：

• 不對實現成本做過高預期、不在未評審情況下對任何需求打包票：在處理第一個需求的時候，作為産品我低估了它的實現難度，導緻我們在和運營對方案時保證這個需求可以做，但實際研發評審時發現并非如此；
• 提前了解業務價值：由于驚喜盒子和預售的需求是同時推動的，所以在處理這個需求的時候我依然忽略了業務價值的問題，包括運營目前配置的商品數量有多少、目前有另一個替代工具為什麼無法滿足、以及開放給商家後商家的使用頻率和上傳數量有多少；
• 注重與業務了解需求中涉及的細節：平台針對定金金額的範圍有更複雜和詳細的限制，但我在做産品調研時，僅從系統提示的内容判斷，丢失了其他限制，而這個内容是需要和運營了解的。

在去做這個判斷的時候我犯了兩個錯誤：對需求中涉及的規則沒有更詳細了解，尤其是當調研時發現平台對定金金額做了限制，應該去思考是否有其他限制；沒有和業務方了解更多信息，業務方會默認你知道。

兩個需求的複雜度都不高，是入職前期熟悉産品流程、了解溝通協調的練手項目，但處理需求的過程中，無論是在方案産出、需求評審還是後續上線，都踩了不少坑，也讓我認識到産品經理是需要對需求的整個過程負責的：在接到需求時需要判斷價值、在輸出方案時需要思考需求的實現成本與更優方案、在需求評審時需要讓研發清楚背景與收益、在開發過程中遇到問題需要及時判斷哪些可以放棄（實際研發時，研發也會發現其他成本高/不合理的地方，産品需要判斷能不能做、怎麼做以及如果不做是否有影響）、在實際上線後需要考慮收益是否達到預期，遇到bad case如何處理。

二、促銷場景的調研與拓展性需求

這個模塊是在制定平台促銷的底層規則、拓展新的促銷場景和營銷工具，屬于較為散、且無具像化産品的模塊。

平台促銷的類型衆多，彼此間的生效邏輯也較為複雜，産品需要定義其生效邏輯以保證減少用戶參與促銷時的理解成本、提升用戶享受的促銷力度、同時保證商家不會讓利過度，這裡的底層定義我并未參與，平台目前的底層邏輯定義已經較為成熟，我所做的工作僅是調研和梳理現存的規範并發現改進點。

雖然底層的規則目前較為固定，但平台營銷的玩法卻并不完善，因而即使作為B端，我們也要去發現新的營銷玩法，并且為這些玩法提供工具支持，從配置和生效側去定義活動玩法，同時考慮一些C端的承接場景。

1. 促銷規則調研

1）調研背景

• 平台目前的促銷規則經過幾輪叠代，加上pm的更新，因而缺少最新的調研文檔參考
• 我們希望從當前的規則中查找不合理的地方，修正并提出新的規則

2）調研過程

整個調研過程經曆三個階段：

在這個過程中，我了解了電商促銷的整體體系，總結如下：

整體來說，我們有兩個角度的維度，從玩法來說，分為預售、單品、多品和券，從範圍來說，分為平台、店鋪、全店和指定商品。

• 平台維度是由平台運營配置、商家參與報名
• 店鋪維度則是商家可以自主配置。

在這些維度下會有更細一層的玩法劃分，例如超級單品促銷下劃分為限時購、閃購、會員福利購和新人價。

在更細一層的玩法中，玩法之間會存在生效規則，即互斥、優先級和不可疊加

• 互斥：在配置側就限制住、不允許商家同時配置
• 優先級：在生效側會在n個生效時間交叉的促銷活動中優先展示一個
• 不可疊加：是在結算側限制用戶在n個活動中隻能參與其中某幾個。

3）調研複盤

最初接到促銷規則調研時，我沒有任何的頭緒，整理出的初版内容沒有任何個人的思考，在後續不斷對接、修改和看競品後，勉強算是梳理了框架，也有了一些感知，總結我個人的調研方法如下：

• 明确調研目标：目标抓準了才會有頭緒，在确定大目标後需要拆解小目标，然後以此為目标針對性調研；
• 梳理曆史文檔：詳細閱讀公司内部的相關文檔，提出疑問點、尋找文檔之間的共同點，然後理出這塊内容的框架，這個框架可以為自己的調研提供方向；
• 梳理現狀，必要時調研競品：按照框架梳理現狀，并根據目标輸出調研結論。
  • 注意文檔的可讀性：内部沉澱的文檔往往會供其他同學查閱，因而要站在不了解這塊業務的同學的角度。
  • 競品調研的思路：确定目标——根據目标通讀相關資料或體驗産品——梳理現狀，提出啟發點。

2. 裂變券工具搭建

1）需求背景

在大促期間，C端産品策劃了裂變券活動并取得了不錯的轉化率，并且目前淘寶和京東都支持商家自建裂變券，因此B端需要将裂變券工具沉澱為商家自運營的玩法。

2）需求分析

整個券工具的搭建分為幾個模塊：

• 底層券模版：券的結構分為券模版和單券，舉個例子，滿300-40的平台券是一個券模版，但用戶領到一張滿300-40的平台券是一張單券。券模版定義了券的字段，包括券類型、可領時間、可用時間、優惠門檻等等；
• 券推廣渠道：即商家建好的裂變券需要在C端的哪些渠道露出和推廣，我們需要提前設想好，并制定露出的規則；
• 活動限制：如何限制用戶的行為（發起用戶 助力用戶），從而确保在為商家帶來流量、用戶願意參與的前提下，商家不會讓利過度、平台和商家不會被薅羊毛；
• 與C端的合作與界限：裂變活動在B端創建、在C端露出，因而這是一個BC端聯動的需求，我們需要和C端産品了解他們的産品方案，以及哪些工作應該由我們推動、哪些由他們推動。

在接到需求後，我首先針對淘寶的裂變券玩法做了系統的調研，梳理完畢後根據我們的券模版梳理券的字段以及限制條件、推廣渠道的露出規則。

3）需求複盤

整個需求處理過程中難度并沒有很大，前期比較系統的競品調研帶來了很多的啟發，比較難以确定的點主要在于裂變券父券（分享者可領的券）的力度限制、透出邏輯，這些問題在和mentor對接以及需求評審後都基本解決。

這個需求是我離職前的最後一個需求，在這個過程中我能感受到自己入職以來的成長：

• 在做競品調研時比之前更有方向，更能梳理出框架；
• 需求評審中，在遇到其他産品與研發同學提出的質疑時，我在會前有過預判，并且能夠給出我的方案設計的原因，以及競品的做法。

在這裡，我将産品設計的流程總結如下：

• 競品調研：這裡不僅包括實際的競品，也包括項目啟動前的其他相關需求，例如裂變券的需求我也需要查看C端産品的裂變方案；
• 梳理産品框架：做完調研後，能夠做到對需求有基本的感知，此時需要梳理做這個需求會涉及哪些内容、哪些相關方，理出框架；
• 設計詳細的産品方案：在這個過程中還需要詳細思考方案的可行性，與前文我在商家後台體驗需求中提到的類似，不再贅述。

三、價格中台的叠代性需求

價格中台主要為C端各個業務場景提供價格計算的能力，這個模塊的業務價值有兩方面：

1. 保證所有場景的到手價規範一緻，
2. 降低其他業務重複造輪子的成本。

在這個模塊中我主要負責叠代兩個需求：

1. 到手價規則叠代

1）需求背景

到手價用于為用戶展示商品實際到手的價格，我們會在商品原價的基礎上為用戶減掉能夠享受的優惠，目前首頁、店鋪、場次（電商平台中的會場，例如大促會場）和搜索場景均已接入中台，但商品詳情頁沒有，并且我們和商詳的計算規則存在部分不一緻，導緻内外展示的價格不一緻。

到手價規則在我接手期間經曆兩次叠代：

• 預售商品的價格計算規則叠代：在三八預售期間，我們發現諸多商品在會場中的價格和商詳不一緻，會影響用戶轉化甚至引起客訴，因而緊急修改了這一塊的規則；
• 商品多件多折、商品有單品促銷且有會員價的計算規則叠代：後續微商詳（可以參考目前淘寶從首頁到商詳中間的商品卡片流）重構需要接入價格中台，商詳與中台的不一緻會阻礙微商詳重構的進程。

2）需求複盤

在處理預售價格叠代的需求的過程中，我主要承擔溝通協調的工作，一方面是因為本身規則不一緻的點并不難找，研發側在線上case出來後就發現了不一緻的點，另一方面是預售的需求是緊急處理上線，因而拉齊大家的進度，确定是否有其他bad case更為重要。

溝通協調在産品經理的日常工作中尤其重要，我從自身的經驗出發，總結一下日常工作中如何溝通協調：

• 前提是了解要溝通什麼：即有哪些事情/問題與誰溝通，首先要對自己接手的需求有所了解，了解後發現其中的相關方及需要與相關方确定的疑問；
• 對接不熟悉相關方前做好功課：如果遇到不太熟悉的相關方，盡量了解一下對方的業務或者準備好問題，否則和對方對接可能一臉懵逼；
• 一次溝通僅拉最需要的人：在找相關方時，我們有時會在一次會議中拉上全部，但部分相關方在一次會議中參與度并不多，這會浪費對方的時間，不利于後續的合作；
• 盡可能一次性解決：大家的時間都很有限，所以問題盡量一次解決，反複溝通不僅拖累進度，而且會讓相關方厭煩。

在處理多件多折和單品促銷有會員價的需求時，我的主要難點在于不了解現狀，尤其是商品享受單品促銷且有會員價的需求，我對後端會輸出幾種價格、每種價格的含義并不清楚，僅僅通過簡單的看實際case并不能讓我了解後端應該如何去修改。最後去處理這個需求時，我們和研發詳細了解了當前價格輸出的類型和規則，在這裡不展開具體的類型與規則。

在前幾天的面試中，我被問到如何從産品側而非更改計算規則避免因價格不一緻帶來的客訴？這為我帶來了新的複盤角度，即客訴問題的産品解法，這個問題我還沒有很好的思考點，在這裡暫不展開，歡迎朋友們指教。

2. 商品tag收攏中台

1）需求背景

商品tag是用以展示商品或促銷等信息的标簽，如下：

當前商品tag存在如下問題：

• 目前所有的tag是由後端輸出，前端自行維護，導緻各個場景下的tag露出規則不一緻，并且後續如果有新的tag加進來，維護成本也會很高；
• 當前tag零散、沒有分類，所有tag一起排優先級，如果有新的tag加入則需要重新再排優先級，并會出現部分tag永遠無法露出的情況。

這個需求是由首頁産品提過來的，但做規範需要推動首頁、店鋪、場次和搜索一起，并為所有場景指定一緻的露出規範。

2）需求分析

• 目标：我們需要确定現有的tag在C端有到手價的情況下如何露出，是需要展示還是不展示，展示需要展示哪些tag；
• 需要做什麼：梳理現有的tag，了解後端輸出tag的規則和優先級，了解各場景的露出現狀，最後制定統一的規範。

3）需求複盤

接手到這個需求的最開始我是毫無頭緒的，甚至對于我要做什麼不明确，與需求方對了三次才明确需求目标，之後調研了後端這裡管理的所有tag和優先級，然後與其他場景的産品講述需求背景、了解他們的看法和需求，最後理出了頭緒。

但這個需求做完并不是全部，在梳理的過程中我發現tag的種類太多、也很分散，如果C端想要新增一個tag需要單獨走排期，成本高、後續也不利于維護，因而将tag這件事收到中台一起處理很有必要。中台應該如何去處理呢，這裡給出我的想法：

首先是分組，之前的tag是按着預售、平台促銷（其中包含跨店滿減tag、跨店多件多折tag等）、店鋪促銷這樣來劃分，但這已經是tag維度，如果新增一個tag就又會作為新的分類和原先的比較優先級，因而在這一層之上缺少一個系統的劃分，我這裡簡單看了競品後給出以下分組：

然後是确定分組後輸出的規則，組之間是否有優先級，組内是否有優先級，如何輸出去能滿足各個場景的需求

我認為可以在單個标簽組内對标簽劃分優先級，并讓前端感知優先級，在前端不做動作的情況下，按照默認優先級展示，但若前端有特殊需求，則可将标簽組重新排序。

營銷中台的定位是将電商營銷相關的底層能力都歸結在一起，方便後續業務叠代、減少重複開發的成本，這部分需求為我帶來的更多是長期價值的思考、與各方溝通協調能力的提升，由于這裡的需求本身就足夠複雜，因而我并未經手太多，做出的方案也較簡單，直至目前，我對中台的理解依然是淺顯的、模糊的，這是我離職後需要去多加學習與補充的點。

四、後記

三個月的實習期，我能夠處理的需求不管是複雜度還是周期都有限，但通過這段實習我對電商營銷有了一些基本認知，本篇僅是我對實習期間做過的需求、需求過程中踩過的坑就行複盤，後續還有更多有關電商的内容等待我去學習與輸出（拖更警告）。

這是我的第二段産品實習，是嚴格意義上的第一份完整的産品經曆（上一段由于特殊原因兩個月不到就結束），因而我的思考和認知都非常淺層，也并無太多業務思考，這也是我未來需要彌補的點，非常歡迎各位朋友和前輩私聊或留言，為我提出更多建議~

本文由 @九龍湖業餘快遞員 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部