起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識作為產品經理，我是如何理解產品的功能邊界?
在前段時間的工作中，遇到了這樣一個討論。事情是這樣的，我們要開發一個活動，活動展示，點擊優惠券后，會領取優惠券，領取成功后，會向用戶進行發送短信，討論的點也就是發短信這邊?；顒雍蛢灮萑莾蓚€不同的產品功能，短信肯定是調用消息通知進行發送，那誰要去觸發這個短信，也就是發短信應該是在活動端還是在優惠券端？
一位同事認為是優惠券端發送的，思路是這樣的，優惠券領取是否成功和優惠券的相關信息，比如金額、限制，是在優惠券端的，而且領取成功后，調用消息通知也是順的。其他的產品同事也認可這樣的方式。流程圖如下：
而我持的觀點為：發送短信應該是活動端進行調用的，而不是優惠券端，流程圖如下：
下面我就闡述一下我的觀點。其實但就這個問題來講，一個很核心的點就是優惠券和活動的對應關系。在我看來，優惠券和活動應該是多對一的關系，也就是一個活動會發送多張優惠券。
就比如滴滴活動時，會發送一堆券給到用戶，去涵蓋比如打車、專車、拼車等多項業務，多種價格，就是很典型的多張優惠券對應一個活動的形式。
假設發短信放到優惠券端，在優惠券領取成功之后，就會發送短信，那如果出現一次性可以領取多張券的情況，就會出現用戶收到多條短信的情況，在整個用戶體驗和短信成本兩邊考慮都是不合適的。
而將短信的發送放到活動端時，就會很好的避免這個問題，當券領取成功后，統一發一條短信給到用戶，同時短信內容還可以根據活動進行自定義，不管是用戶體驗的角度還是短信成本的考慮，都是最合適的選擇。
借助這個例子，我想引出這樣一個概念：產品的功能邊界。在產品中，每個功能不應該是無限擴展的，而是有它的邊界和限制，而決定功能邊界和限制的就是功能自身的屬性決定的。
就那上面的例子來看，對于優惠券來講，他的自身屬性就是限制和優惠金額。限制是使用的一個限制，比如滴滴發的專車券，只能在預約專車服務，進行支付時使用。根據不同的業務和場景，限制有很多，比如平臺限制、業務限制、時間限制、金額等。優惠金額是指在使用時可以抵扣或者優惠的金額。一般有固定金額和不固定金額。固定金額就是創建優惠券時，就設定的金額，比如滿減券，滿1000元減100元，也就是優惠券的金額是優惠100元。還有就是不固定金額，比如7折券，不確定具體的優惠金額，而是根據限制和具體使用時，進行確定。
對于活動來講，活動的自身屬性就是展示和推廣。展現主要是活動的展現形式，包括產品等其他信息。推廣主要是比如領券、分享等。
也就是從短信來看，應該屬于活動的推廣部分，因此應該是從活動這邊進行發送。
那么，根據產品的功能邊界去設計產品，有什么好處呢？
從產品的角度來看，功能應該是獨立和模塊化的，產品只是根據業務和用戶體驗，在不同的頁面，拼接不同的功能模塊，從而達到產品體驗的最大化，同時使產品富有靈活性和可擴展性的特性。
我常常具這樣的例子，產品的功能就如同樂高一塊塊獨立的積木，而產品就是通過不同積木組合，依據業務需求和產品經理的一點奇思妙想，拼出來的模型。而積木與積木之前拼合在一起的只是那簡單的幾個卡扣而已。一旦某一塊積木出現問題或需要調整，只需要動到那一塊積木和與之相連的即可。
通過借助產品的功能邊界，去設計功能，從產品金字塔最低端的細小功能點一點點去設計，到后來功能塊、功能、頁面，乃至整個產品，看似是個完整的整體，其實里面又獨立者大大小小的個體，通過個體與個體之間的獨立又緊密配合，來達到整體的配合，無疑這是最完美的情況。
如果將功能按照功能邊界的思維進行拆分和整合，你會發現，當你再做另個產品時，可能只需要對功能模塊進行重新排列，就可實現了。如果一個需求到了這邊，你也會能夠準確的分析出，涉及到的功能點和影響范圍，從而更輕松的應對需求，實現更好的產品迭代。
本文由 @藍胖子_ Simon 原創發布于人人都是產品經理?，未經許可，禁止轉載。
本文重點講述的是功能邊界劃分的意義，而不是如何鑒定功能邊界劃分原則
如果真從成本出發，領完優惠券可以不發短信，因為APP本身就有頁面反饋?？爝^期的時候發送短信不是更好 1.告知用戶他有多少券 2.變相提醒用戶重返APP
其實光從這個例子來說的話，還是覺得做在優惠券端比較好，原因是因為最終是否領券成功是要看優惠券端的處理是否成功，而不是返回商城是否成功，而且假如返回商城后領取成功結果加載失敗，那這個券有可能就發不出來了。
至于一對多導致發多條短信的問題，我覺得也很好解決，可以判斷拿多張優惠券的請求是不是來自同一個商城訂單發起的（用訂單號即可判斷），同一個訂單發起的獲取優惠券請求則只發一條短信就好。
其實還是要做在活動這端的，推送短信模版的內容，應該是跟著活動的上下文走的。優惠券端只是負責優惠券的使用時間、金額等基本屬性的限制。具體什么渠道發放，發放限制多少跟著活動的場景走的。所以短信這邊也放在活動那邊妥妥的。
?? 我看了之后還是覺得要放到優惠券一端。針對領多張券的情況，短信通知可以延時5分鐘，將五分鐘內的優惠券通過一條短信發出來。
完全看不懂啊，捉急。
??
這和 開發是做的技術架構的思路如出一轍。
虛
璐璐學習了。
??
個人持不同觀點，首先作為用戶，在“獲取優惠券”時更希望得到即時回饋，即每領一張就馬上得到通知，而不是領完之后，返回之前，不能確定是否領取成功，可能會產生重復領取或者退出領取界面，中止對其它優惠券的查看。在“使用優惠券”時候，每一條短信或通知是分開的，那么也便于查看管理，可以歸類存檔也可以用一條刪一條。一大坨優惠券集中在一起，在使用場景會造成干擾和效率降低。
其次作為PM，個人認為，1、看下行業內其它人是怎么做的。包括大型電商、團購等網站，基本都是使用的“即時發送確認”的策略，不說盲目迷信權威吧，至少說明這種做法會有它的道理和優勢；2、功能邊界什么的都是自己的腦補，用戶說了才算。解決辦法就是做用研，或者小范圍的AB測試，或者事后采集數據分析（但是會浪費時間和成本，并且如果造成活動中的流失或其它損害，基本不可逆），而不是“我覺得這樣好”就直接上。
其實這里作者木有描述清場景和業務目的：
1. 如果目的只是提醒用戶，你成功的領取了個優惠券。那么，正常邏輯來說，優惠券領取后系統都會回饋（多正常的交互流程… )，比如『恭喜親，優惠券已放入您的賬戶』—— 這屬于即時回饋，這種反饋信息放到最后提醒就沒有必要了。頂多下次進入的產品的時候提醒用戶使用就好了，也沒有重發短信的必要。
2. 如果目標是，在用戶關閉活動頁或產品后，引導他再次打開。那么，除去1外，用戶推出活動后，可以已『親本次活動領取了多少優惠券』為由頭，向用戶發送短信，引導用戶二次打開產品或進行消費。
贊同，按筆者描述的場景，個人認為不管是領券后，還是返回活動頁，都無需向用戶推送短信（此處短信我理解為手機短信），此時用戶本身就在操作中的頁面，可以通過站內推送消息方式通知，推送短信反而會中斷用戶當前的操作。
有個前提假設，活動很多時候是要拉那些還沒有安裝app的新用戶