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

商家后臺的體驗(yàn)性需求：商家后臺服務(wù)于自營店鋪和第三方商家，里面的板塊眾多，我只承接來自促銷板塊的需求，這里的兩個體驗(yàn)性需求是我在剛?cè)肼殨r做的，難度不高，主要用于熟悉產(chǎn)品流程，但后來復(fù)盤時發(fā)現(xiàn)也有較多值得思考與改進(jìn)的點(diǎn)。

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

價格中臺的迭代性需求：價格中臺主要為小紅書C端各個業(yè)務(wù)場景提供價格計算能力，有長期業(yè)務(wù)價值、需求復(fù)雜度也較高，但我所承接的需求的實(shí)際方案并不復(fù)雜，在這個需求中比較困難的點(diǎn)在兩個方面：溝通與協(xié)調(diào)各個C端業(yè)務(wù)場景；梳理現(xiàn)存的規(guī)則找出不合理性。

一、商家后臺的體驗(yàn)性需求

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

1. 驚喜盒子活動報名流程優(yōu)化

1）需求背景

驚喜盒子是小紅書內(nèi)給用戶發(fā)優(yōu)惠券的場景之一，用戶在逛社區(qū)筆記的過程中，會掉落驚喜盒子券，促進(jìn)用戶從社區(qū)轉(zhuǎn)化到商城購物。這個需求來源于負(fù)責(zé)收集與審核驚喜盒子券的運(yùn)營同學(xué)，商家每月會提報一定數(shù)量的券，整個流程為：

整個流程出現(xiàn)了以下問題：

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

2）需求分析

分析后發(fā)現(xiàn)，出現(xiàn)這兩個問題的原因在于：

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

3）需求復(fù)盤

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

• 需求評審時被質(zhì)疑有實(shí)現(xiàn)復(fù)雜度更低的方案；
• 評審過程中開發(fā)提出當(dāng)前方案會影響系統(tǒng)中的其他部分，影響商家的判斷；
  • 在通知商家不通過的方案中，我的提示話術(shù)是“您有一條活動報名不通過”，這會讓商家誤認(rèn)為這里的提示是針對所有類型的活動報名，但我們本次的需求僅針對驚喜盒子類型。
• 開發(fā)過程中研發(fā)需要相關(guān)的提報情況數(shù)據(jù)，作為開發(fā)成本的判斷

通過這個需求遇到的問題給我?guī)淼?strong>思考：

• 業(yè)務(wù)價值的判斷：這是我前期在做需求時感悟最深的點(diǎn)，需求的實(shí)現(xiàn)最終是為了推動業(yè)務(wù)發(fā)展的，因而在接到一個需求前首先需要明確的就是這個業(yè)務(wù)的價值有多高；
• 提前思考方案的實(shí)現(xiàn)復(fù)雜度：當(dāng)前是最優(yōu)方案嗎？有沒有替代性方案？這個方案與替代性方案相比有什么優(yōu)點(diǎn)和不足？這里的優(yōu)點(diǎn)是否值得去做更高成本的投入？
• 方案設(shè)計時考慮對相關(guān)模塊的影響：由于B端的需求之間聯(lián)系密切，往往牽一發(fā)而動全身，因而去改動系統(tǒng)中一個邏輯時需要更全面的思考它的影響范圍，這里的影響范圍不僅是其他板塊，也可能是其他業(yè)務(wù)方；
• 產(chǎn)品文案打磨：在設(shè)計產(chǎn)品的過程中避不開一些文案撰寫，比如功能名稱、提示語、頁面引導(dǎo)語等。

2. 預(yù)售管理體驗(yàn)優(yōu)化

1）需求背景

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

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

• 可以支持多選預(yù)售狀態(tài)導(dǎo)出預(yù)售數(shù)據(jù)
• 已終止的預(yù)售ID，支持查看詳情
• 商品價格落入“真空價格區(qū)間”（報關(guān)商品會出現(xiàn)的價格校驗(yàn)區(qū)間）報錯提示更詳細(xì)
• 可批量配置定金預(yù)售

2）需求分析

以上的四個需求，前三個主要在于新增入口或功能，并無太多方案產(chǎn)出的空間，需要產(chǎn)品推動研發(fā)實(shí)現(xiàn)，主要集中在最后一個需求，需要考慮批量配置的方式和流程：

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

3）需求復(fù)盤

處理這個項(xiàng)目遇到的主要問題有：

• 需求被砍：在評審過程中，多選預(yù)售狀態(tài)的需求實(shí)現(xiàn)難度比我們想象的要大很多，加上研發(fā)認(rèn)為當(dāng)前分幾次導(dǎo)出的工作量并沒有這么大，因而這個需求被否掉了
• 需求價值被質(zhì)疑：在開發(fā)過程中，批量配置的后端工作量超出預(yù)期，需要后端重新寫一套邏輯，花費(fèi)了3pd去做這件事，導(dǎo)致研發(fā)在此期間一直有問我日常預(yù)售商品的配置數(shù)量如何
• 上線后發(fā)現(xiàn)影響較大的錯誤：在三八大促預(yù)售配置當(dāng)晚，自營運(yùn)營同學(xué)發(fā)現(xiàn)定金校驗(yàn)的規(guī)則是不完全的，實(shí)際校驗(yàn)規(guī)則比我最初制定的要更復(fù)雜

為我?guī)淼乃伎迹?/p>

• 不對實(shí)現(xiàn)成本做過高預(yù)期、不在未評審情況下對任何需求打包票：在處理第一個需求的時候，作為產(chǎn)品我低估了它的實(shí)現(xiàn)難度，導(dǎo)致我們在和運(yùn)營對方案時保證這個需求可以做，但實(shí)際研發(fā)評審時發(fā)現(xiàn)并非如此；
• 提前了解業(yè)務(wù)價值：由于驚喜盒子和預(yù)售的需求是同時推動的，所以在處理這個需求的時候我依然忽略了業(yè)務(wù)價值的問題，包括運(yùn)營目前配置的商品數(shù)量有多少、目前有另一個替代工具為什么無法滿足、以及開放給商家后商家的使用頻率和上傳數(shù)量有多少；
• 注重與業(yè)務(wù)了解需求中涉及的細(xì)節(jié)：平臺針對定金金額的范圍有更復(fù)雜和詳細(xì)的限制，但我在做產(chǎn)品調(diào)研時，僅從系統(tǒng)提示的內(nèi)容判斷，丟失了其他限制，而這個內(nèi)容是需要和運(yùn)營了解的。

在去做這個判斷的時候我犯了兩個錯誤：對需求中涉及的規(guī)則沒有更詳細(xì)了解，尤其是當(dāng)調(diào)研時發(fā)現(xiàn)平臺對定金金額做了限制，應(yīng)該去思考是否有其他限制；沒有和業(yè)務(wù)方了解更多信息，業(yè)務(wù)方會默認(rèn)你知道。

兩個需求的復(fù)雜度都不高，是入職前期熟悉產(chǎn)品流程、了解溝通協(xié)調(diào)的練手項(xiàng)目，但處理需求的過程中，無論是在方案產(chǎn)出、需求評審還是后續(xù)上線，都踩了不少坑，也讓我認(rèn)識到產(chǎn)品經(jīng)理是需要對需求的整個過程負(fù)責(zé)的：在接到需求時需要判斷價值、在輸出方案時需要思考需求的實(shí)現(xiàn)成本與更優(yōu)方案、在需求評審時需要讓研發(fā)清楚背景與收益、在開發(fā)過程中遇到問題需要及時判斷哪些可以放棄（實(shí)際研發(fā)時，研發(fā)也會發(fā)現(xiàn)其他成本高/不合理的地方，產(chǎn)品需要判斷能不能做、怎么做以及如果不做是否有影響）、在實(shí)際上線后需要考慮收益是否達(dá)到預(yù)期，遇到bad case如何處理。

二、促銷場景的調(diào)研與拓展性需求

這個模塊是在制定平臺促銷的底層規(guī)則、拓展新的促銷場景和營銷工具，屬于較為散、且無具像化產(chǎn)品的模塊。

平臺促銷的類型眾多，彼此間的生效邏輯也較為復(fù)雜，產(chǎn)品需要定義其生效邏輯以保證減少用戶參與促銷時的理解成本、提升用戶享受的促銷力度、同時保證商家不會讓利過度，這里的底層定義我并未參與，平臺目前的底層邏輯定義已經(jīng)較為成熟，我所做的工作僅是調(diào)研和梳理現(xiàn)存的規(guī)范并發(fā)現(xiàn)改進(jìn)點(diǎn)。

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

1. 促銷規(guī)則調(diào)研

1）調(diào)研背景

• 平臺目前的促銷規(guī)則經(jīng)過幾輪迭代，加上pm的更新，因而缺少最新的調(diào)研文檔參考
• 我們希望從當(dāng)前的規(guī)則中查找不合理的地方，修正并提出新的規(guī)則

2）調(diào)研過程

整個調(diào)研過程經(jīng)歷三個階段：

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

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

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

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

在更細(xì)一層的玩法中，玩法之間會存在生效規(guī)則，即互斥、優(yōu)先級和不可疊加

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

3）調(diào)研復(fù)盤

最初接到促銷規(guī)則調(diào)研時，我沒有任何的頭緒，整理出的初版內(nèi)容沒有任何個人的思考，在后續(xù)不斷對接、修改和看競品后，勉強(qiáng)算是梳理了框架，也有了一些感知，總結(jié)我個人的調(diào)研方法如下：

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

2. 裂變?nèi)ぞ叽罱?/h2>

1）需求背景

在大促期間，C端產(chǎn)品策劃了裂變?nèi)顒硬⑷〉昧瞬诲e的轉(zhuǎn)化率，并且目前淘寶和京東都支持商家自建裂變?nèi)?，因此B端需要將裂變?nèi)ぞ叱恋頌樯碳易赃\(yùn)營的玩法。

2）需求分析

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

• 底層券模版：券的結(jié)構(gòu)分為券模版和單券，舉個例子，滿300-40的平臺券是一個券模版，但用戶領(lǐng)到一張滿300-40的平臺券是一張單券。券模版定義了券的字段，包括券類型、可領(lǐng)時間、可用時間、優(yōu)惠門檻等等；
• 券推廣渠道：即商家建好的裂變?nèi)枰贑端的哪些渠道露出和推廣，我們需要提前設(shè)想好，并制定露出的規(guī)則；
• 活動限制：如何限制用戶的行為（發(fā)起用戶+助力用戶），從而確保在為商家?guī)砹髁?、用戶愿意參與的前提下，商家不會讓利過度、平臺和商家不會被薅羊毛；
• 與C端的合作與界限：裂變活動在B端創(chuàng)建、在C端露出，因而這是一個BC端聯(lián)動的需求，我們需要和C端產(chǎn)品了解他們的產(chǎn)品方案，以及哪些工作應(yīng)該由我們推動、哪些由他們推動。

在接到需求后，我首先針對淘寶的裂變?nèi)娣ㄗ隽讼到y(tǒng)的調(diào)研，梳理完畢后根據(jù)我們的券模版梳理券的字段以及限制條件、推廣渠道的露出規(guī)則。

3）需求復(fù)盤

整個需求處理過程中難度并沒有很大，前期比較系統(tǒng)的競品調(diào)研帶來了很多的啟發(fā)，比較難以確定的點(diǎn)主要在于裂變?nèi)溉ǚ窒碚呖深I(lǐng)的券）的力度限制、透出邏輯，這些問題在和mentor對接以及需求評審后都基本解決。

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

• 在做競品調(diào)研時比之前更有方向，更能梳理出框架；
• 需求評審中，在遇到其他產(chǎn)品與研發(fā)同學(xué)提出的質(zhì)疑時，我在會前有過預(yù)判，并且能夠給出我的方案設(shè)計的原因，以及競品的做法。

在這里，我將產(chǎn)品設(shè)計的流程總結(jié)如下：

• 競品調(diào)研：這里不僅包括實(shí)際的競品，也包括項(xiàng)目啟動前的其他相關(guān)需求，例如裂變?nèi)男枨笪乙残枰榭碈端產(chǎn)品的裂變方案；
• 梳理產(chǎn)品框架：做完調(diào)研后，能夠做到對需求有基本的感知，此時需要梳理做這個需求會涉及哪些內(nèi)容、哪些相關(guān)方，理出框架；
• 設(shè)計詳細(xì)的產(chǎn)品方案：在這個過程中還需要詳細(xì)思考方案的可行性，與前文我在商家后臺體驗(yàn)需求中提到的類似，不再贅述。

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

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

1. 保證所有場景的到手價規(guī)范一致，
2. 降低其他業(yè)務(wù)重復(fù)造輪子的成本。

在這個模塊中我主要負(fù)責(zé)迭代兩個需求：

1. 到手價規(guī)則迭代

1）需求背景

到手價用于為用戶展示商品實(shí)際到手的價格，我們會在商品原價的基礎(chǔ)上為用戶減掉能夠享受的優(yōu)惠，目前首頁、店鋪、場次（電商平臺中的會場，例如大促會場）和搜索場景均已接入中臺，但商品詳情頁沒有，并且我們和商詳?shù)挠嬎阋?guī)則存在部分不一致，導(dǎo)致內(nèi)外展示的價格不一致。

到手價規(guī)則在我接手期間經(jīng)歷兩次迭代：

• 預(yù)售商品的價格計算規(guī)則迭代：在三八預(yù)售期間，我們發(fā)現(xiàn)諸多商品在會場中的價格和商詳不一致，會影響用戶轉(zhuǎn)化甚至引起客訴，因而緊急修改了這一塊的規(guī)則；
• 商品多件多折、商品有單品促銷且有會員價的計算規(guī)則迭代：后續(xù)微商詳（可以參考目前淘寶從首頁到商詳中間的商品卡片流）重構(gòu)需要接入價格中臺，商詳與中臺的不一致會阻礙微商詳重構(gòu)的進(jìn)程。

2）需求復(fù)盤

在處理預(yù)售價格迭代的需求的過程中，我主要承擔(dān)溝通協(xié)調(diào)的工作，一方面是因?yàn)楸旧硪?guī)則不一致的點(diǎn)并不難找，研發(fā)側(cè)在線上case出來后就發(fā)現(xiàn)了不一致的點(diǎn)，另一方面是預(yù)售的需求是緊急處理上線，因而拉齊大家的進(jìn)度，確定是否有其他bad case更為重要。

溝通協(xié)調(diào)在產(chǎn)品經(jīng)理的日常工作中尤其重要，我從自身的經(jīng)驗(yàn)出發(fā)，總結(jié)一下日常工作中如何溝通協(xié)調(diào)：

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

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

在前幾天的面試中，我被問到如何從產(chǎn)品側(cè)而非更改計算規(guī)則避免因價格不一致帶來的客訴？這為我?guī)砹诵碌膹?fù)盤角度，即客訴問題的產(chǎn)品解法，這個問題我還沒有很好的思考點(diǎn)，在這里暫不展開，歡迎朋友們指教。

2. 商品tag收攏中臺

1）需求背景

商品tag是用以展示商品或促銷等信息的標(biāo)簽，如下：

當(dāng)前商品tag存在如下問題：

• 目前所有的tag是由后端輸出，前端自行維護(hù)，導(dǎo)致各個場景下的tag露出規(guī)則不一致，并且后續(xù)如果有新的tag加進(jìn)來，維護(hù)成本也會很高；
• 當(dāng)前tag零散、沒有分類，所有tag一起排優(yōu)先級，如果有新的tag加入則需要重新再排優(yōu)先級，并會出現(xiàn)部分tag永遠(yuǎn)無法露出的情況。

這個需求是由首頁產(chǎn)品提過來的，但做規(guī)范需要推動首頁、店鋪、場次和搜索一起，并為所有場景指定一致的露出規(guī)范。

2）需求分析

• 目標(biāo)：我們需要確定現(xiàn)有的tag在C端有到手價的情況下如何露出，是需要展示還是不展示，展示需要展示哪些tag；
• 需要做什么：梳理現(xiàn)有的tag，了解后端輸出tag的規(guī)則和優(yōu)先級，了解各場景的露出現(xiàn)狀，最后制定統(tǒng)一的規(guī)范。

3）需求復(fù)盤

接手到這個需求的最開始我是毫無頭緒的，甚至對于我要做什么不明確，與需求方對了三次才明確需求目標(biāo)，之后調(diào)研了后端這里管理的所有tag和優(yōu)先級，然后與其他場景的產(chǎn)品講述需求背景、了解他們的看法和需求，最后理出了頭緒。

但這個需求做完并不是全部，在梳理的過程中我發(fā)現(xiàn)tag的種類太多、也很分散，如果C端想要新增一個tag需要單獨(dú)走排期，成本高、后續(xù)也不利于維護(hù)，因而將tag這件事收到中臺一起處理很有必要。中臺應(yīng)該如何去處理呢，這里給出我的想法：

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

然后是確定分組后輸出的規(guī)則，組之間是否有優(yōu)先級，組內(nèi)是否有優(yōu)先級，如何輸出去能滿足各個場景的需求

我認(rèn)為可以在單個標(biāo)簽組內(nèi)對標(biāo)簽劃分優(yōu)先級，并讓前端感知優(yōu)先級，在前端不做動作的情況下，按照默認(rèn)優(yōu)先級展示，但若前端有特殊需求，則可將標(biāo)簽組重新排序。

營銷中臺的定位是將電商營銷相關(guān)的底層能力都?xì)w結(jié)在一起，方便后續(xù)業(yè)務(wù)迭代、減少重復(fù)開發(fā)的成本，這部分需求為我?guī)淼母嗍?strong>長期價值的思考、與各方溝通協(xié)調(diào)能力的提升，由于這里的需求本身就足夠復(fù)雜，因而我并未經(jīng)手太多，做出的方案也較簡單，直至目前，我對中臺的理解依然是淺顯的、模糊的，這是我離職后需要去多加學(xué)習(xí)與補(bǔ)充的點(diǎn)。

四、后記

三個月的實(shí)習(xí)期，我能夠處理的需求不管是復(fù)雜度還是周期都有限，但通過這段實(shí)習(xí)我對電商營銷有了一些基本認(rèn)知，本篇僅是我對實(shí)習(xí)期間做過的需求、需求過程中踩過的坑就行復(fù)盤，后續(xù)還有更多有關(guān)電商的內(nèi)容等待我去學(xué)習(xí)與輸出（拖更警告）。

這是我的第二段產(chǎn)品實(shí)習(xí)，是嚴(yán)格意義上的第一份完整的產(chǎn)品經(jīng)歷（上一段由于特殊原因兩個月不到就結(jié)束），因而我的思考和認(rèn)知都非常淺層，也并無太多業(yè)務(wù)思考，這也是我未來需要彌補(bǔ)的點(diǎn)，非常歡迎各位朋友和前輩私聊或留言，為我提出更多建議~

—— 歡迎在線投稿 ——

特別提示：關(guān)注本專欄，別錯過行業(yè)干貨！

PS：本司承接 小紅書推廣/抖音推廣/百度系推廣/知乎/微博等平臺推廣：關(guān)鍵詞排名，筆記種草，數(shù)據(jù)優(yōu)化等；

咨詢微信：139 1053 2512 (同電話)

首席增長官CGO薦讀：

• 《增長導(dǎo)航：高效增長工具整理》
• 《小紅書推廣：筆記排名，代寫代發(fā)，探店合作》
• 《淘寶逛逛營銷推廣：KOC種草，達(dá)人筆記，筆記撰寫，拍照攝影》

更多精彩，關(guān)注：增長黑客（GrowthHK.cn）

增長黑客（Growth Hacker）是依靠技術(shù)和數(shù)據(jù)來達(dá)成各種營銷目標(biāo)的新型團(tuán)隊(duì)角色。從單線思維者時常忽略的角度和高度，梳理整合產(chǎn)品發(fā)展的因素，實(shí)現(xiàn)低成本甚至零成本帶來的有效增長…