我們做產品很多時候會有一些疑慮：
有時候我們會搞不太清楚哪些需求是否該滿足
哪些需求什么時候滿足
哪些需求該怎么滿足
有人認為這是在評估需求，考察的是產品人員對需求的理解和控制能力。誠然，這么說也沒錯，但是在筆者看來，這更應該是產品經理對產品邊界的理解。
筆者個人是從下面三個方面對產品邊界的認識 ：
- 產品定位需要明確的產品邊界
- 產品版本需要明確的產品邊界
- 產品功能需要明確的產品邊界
下面筆者將依次說明自己對幾點的理解和認識：
-
產品定位需要明確產品邊界
這一點的意思就是說我們要明確自己產品的定位，哪些來自市場和用戶的需求是自家產品應該解決的。各位作為優秀的產品經理一定會發現生活中各種未被滿足的需求，對我們而言，和我們的產品定位不匹配的需求都沒有實際意義。
筆者曾經做過一個餐飲項目，當時我們的定位是做一個餐飲SAAS產品，為餐飲門店提供一套更加靈活的餐飲一體化解決方案。那么在服務餐飲門店的外賣業務時，我們內部就有了一些關于產品的討論：
甲方觀點：我們可以自己做一個外賣訂餐產品
乙方觀點：我們需要做的是和現有的外賣平臺對接。
甲方的理由是這樣做對我們系統而言，訂單都是系統內流轉，我們也可以靈活控制，從完整的產品上來說這是形成了閉環的。
而筆者和另外的小伙伴認為我們做的是餐飲saas產品，不是外賣產品，這和我們自己定位相違背。并且我們自己做外賣訂餐產品和三大外賣巨頭甚至其他小平臺不僅沒有流量上的優勢，更會讓我們陷入到不必要的產品競爭中，白白消耗公司的戰斗力。
所以，當我們自己對自己所參與設計的產品有了一個認定之后，實際上產品本身的邊界也就已經確定了。盲目夸大產品定位的邊界，很有可能會使自己偷雞不成蝕把米 。
2 . 從開發周期上確定產品邊界
我們在做產品迭代時，除開對之前產品設計的優化，還會加入一些新的功能或者模塊，這時候就需要我們清楚的了解當前產品的版本邊界。不要在滿足當前一個未被明確的需求或者尚未成功的模塊功能上進行更多的產品疊加。
有一個關于版本邊界的栗子:
一個網絡展會平臺的產品，在產品當前版本就一定是能夠正常創建展會，相應的展商能夠參加展會并將展品發布出來，在產品本身而言就是一個完整的CMS系統。如果這個時候讓你在增加觀眾報名線下展會的入口，并在相應的報名系統，很顯然這是不太合理的，也明顯不符合當前產品版本的主要目的。
每一次的產品迭代版本都要明確目的，這個目的就是我們這個階段的產品邊界，相應的，超越這個邊界的事情，筆者認為至少在當前的階段是不能夠做的。
3 . 產品設計本身需要確定邊界
在產品中，每個功能不應該是無限擴展的，而是有它的邊界和限制，而決定功能邊界和限制的就是功能自身的屬性決定的.
就像我們在產品里面給用戶發送優惠券的一樣，我們肯定做過產品活動和優惠券的邏輯。比如餓了么外賣，我們每次點完餐之后分享再去領取優惠券，那么領取優惠券的通知應該跟隨用戶參與分享領券活動呢？還是跟隨用戶賬戶獲得優惠券呢？如果領一張優惠券就發送一個通知，那么在餓了么這套邏輯中，用戶獲得系列優惠券就應該會被多次通知得到優惠券，很顯然這樣用戶就會被信息轟炸了。而現實情況，餓了么也是對整個領券活動綜合通知用戶的優惠券獲取情況。
所以在上面餓了么這個例子中，產品的通知邊界應該是控制在活動這樣一個邏輯上面，而非優惠券。
產品設計的時候，對產品邊界的限制是建立在對產品功能模塊的深入理解上的，在設計的時候需要將相應的功能限制在對應的模塊中。
總結
綜合而言，筆者認為在做產品設計時，我們要深刻理解產品的用戶定位和產品各模塊之間的邏輯，不論是隔離還是連接，需要在產品上做到伸展有度
By Tick