【實習復盤】記錄我在小紅書的需求與成長

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

本文記錄我在小紅書電商產品部營銷組的主要工作與收獲，三個月實習期間我承接了來自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）調研過程

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

1. 翻閱歷史文檔
2. 有基本認知后梳理一版初稿
3. 調研競品并做對比

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

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

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

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

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

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

3）調研復盤

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

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

2. 裂變券工具搭建

1）需求背景

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

2）需求分析

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

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

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

3）需求復盤

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

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

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

在這里，我將產品設計的流程總結如下：

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

三、價格中臺的迭代性需求

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

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

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

• 迭代當前到手價的規則
• 統一當前商品tag的露出規范。

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 協議