企業應用SaaS行業的B端產品經理，如果提升自己的產品設計能力？
企業應用SaaS行業的B端產品經理，如果提升自己的產品設計能力？
剛入SaaS的坑不久，除了在工作中自己思考總結，現在線上的內容中大部分都為C端產品經理的思考輸出，比較少關於B端的內容，B端產品經理如果提升自己的工作能力？
後臺產品，顧名思義就是不直接面向用戶的產品。
第一、滿足的需求更多的是業務需求而不是個人的訴求。
第二、產品使用的目的性極強。後臺產品在使用的時候一般都帶有極強的目的性，或需要完成業務方面的操作，或需要完成某些流程的審批，總之在使用的時候一般不會因為個人情感方面的原因去使用。
根據上面這兩點，同樣是在點餐，你去餐廳服務員用手中的手機給你點餐的系統就是一款後臺產品，而你自己點外賣或者掃碼自助點餐就不是。我之前做的一款PDA系統，裡面有個流程與淘寶購物流程十分相似，但它由於是為了輔助業務而開發的所以也是一個後臺產品。基於這兩點，我在我做過的產品中歸納了一些幾種不同的後臺產品形態，並且給它們分了類。
工具類
我總結了工具類產品的幾個特點：
1。使用端一般為移動端。
由於工具類產品的特殊性，所需要的便捷性特別重要，往往需要在不同的場景下使用，使用工具類後臺產品一般都為移動端產品。比如PDA，PAD，手機APP等。所以一般在設計的時候，一定要根據不同的業務場景選擇合適的操作端進行設計。
2。操作性特別強。
相對於其他的後臺產品，工具類產品的操作性特別強。具體來說工具類產品應該是為了滿足某些操作流程，規範化，智慧化，集約化所開發的產品。所以這個時候，使用工具類後臺產品的操作就至關重要，同時也是其唯一的目的。
在設計工具類產品的時候，需要考慮以下幾個方面：
①操作的步驟，輸入按鈕等互動需要多加考量。由於工具類的產品核心功能是操作，如何能在該場景下簡單便捷的達到操作目的，是需要設計者去思考的。
②工具類產品很多時候使用的場景是移動的，而不是和其他後臺產品一樣在電腦上操作的。所以這個時候就需要考慮到工具類產品的使用場景問題。比如在一個大一些的市場裡面使用PDA時訊號可能不太好，那麼弱網環境下的體驗應該如何，圖片是否載入，操作步驟是否要簡化；再如一個飯店的點菜寶，使用者在飯店這樣嘈雜的地方提示音的音量是不是應該大些。
3。相對於其他後臺產品許可權較低，整體比較簡單，功能較單一。
我們一般在提到後臺在產品的時候，第一印象可能就是複雜與繁瑣。但是由於工具類產品的操作人員一般為實際的業務操作人員，所以其許可權一般來說會比較低。同時也因為它可能只是為了滿足某些需求而要做的一套工具。所以由於以上幾個原因工具類產品會比一般後臺產品簡單，功能也會較為單一。
記錄類
記錄類產品指的是在業務人員進行操作的時候，為了以後操作的可溯性，以及工作後期的查漏補缺，當前所需內容的一些記錄等所開發的產品。比如在我最近做的ERP系統裡面，商品的到貨以及入庫都需要進行記錄，同時新採購的商品需要進行錄入，而這些都屬於記錄類的產品。一般來說記錄類的產品不會單獨存在，而是作為某一套大的系統中的一小部分。
我總結了記錄類產品的幾個特點：
1。在規劃欄位的時候，記錄類產品應該加上標識欄位。
由於記錄類產品很大程度上會作為今後某些工作的參考記錄，其資料的流轉性，與其他資料的整合的可能性較高，業務人員的審查更改機率也交大，有時也會有存檔的需要。所以一般記錄類的產品都需要加上一個標識欄位，透過設定好規則的編碼方式給其確定唯一ID。
2。產生新記錄資料時應該思考全面。
在設計記錄類產品的時候，每一條資料的產生方式都是需要仔細思考的。因為其實你整個頁面就是每一條新紀錄的疊加生成的，所以一定要在源頭把控好。
一般來說如果是透過外界業務的原因直接推進到系統做記錄的話，是可以透過在頁面增加新增按鈕來進行新增的，此時應該用彈窗還是新頁面的方式，某些欄位是填寫還是選擇等都需要去思考。如果是在系統內部由於一些業務的流轉直接生成的記錄，那麼從另一個頁面帶過來哪些欄位，去掉哪些欄位，同時需要補錄什麼資訊就是比較重要的點。
另外，在產生資料後這條資料是直接疊加到列表最上面還是有狀態有位置。新增資料後有沒有稽核的流程，稽核需要幾步，稽核過程中資料是否展示出來，展示在什麼位置都有許多可以細化的點。
3。做篩選與搜尋要精簡準確。
做記錄類產品，為了更加精準的定位到所需要的資料，一般都會做篩選與搜尋。從條件上來說，頁面裡面所有的欄位都可以作為篩選與搜尋的條件，但是我們在做的時候，不能僅憑個人習慣來做定奪。要多和業務人員進行溝通，找出他們在操作此類資訊最敏感的欄位是什麼，最好辨別的欄位是什麼，差異性最大的欄位是什麼，然後來做刪選與搜尋條件。篩選與搜尋做的特別精簡但是所能達到的目的卻十分準確才是一個好的篩選搜尋。
4。邊界條件，輸入欄位，操作等限制條件要做到位。
由於記錄類產品的特殊性，需要操作人員輸入大量的資料，這個時候如果不慎操作失誤但是卻沒有發現，就可能出現錯誤，耽誤業務。所以在設計的時候，一定要考慮到這些限制條件。比如該欄位的邊界值為多大多小，欄位允許輸入的合法字元是什麼，一共需要輸入幾位等等這些可以透過正則表示式等技術手段減少錯誤的限制要做到位。同時，不同條件下的該條記錄可能操作也不一樣。這個也需要考慮到。這一點也適用於下文要說到的配置類產品。
5。排序，操作互動等其他小的功能點要考慮全面。
記錄類產品每一條資料的欄位型別都是相同的，所以有時候會涉及到排序功能。那產品經理應該考慮到資料的正常記錄方式是如何的，時間正序還是時間倒序，哪些欄位允許排序，排序的方式是什麼。操作的互動需要思考設計，這個操作是在列表頁面就讓其操作還是需要點進詳情頁必須看完詳情後才可以操作。以及要不要做批次操作的功能等等其他一些這樣小的功能點，產品經理也要根據業務考慮全面。
配置類
配置類產品可以說是後臺產品中較為常見的一種，同時也是涵蓋內容較廣的一種。內容管理配置，活動配置，人員管理配置等等都叫做配置類產品。關於這個系統不同角色的許可權配置，以及其他頁面下拉框的選項配置等等。所以作為一個後臺系統，配置類的專案應該是必不可少的。
常見的單獨配置類產品比如CMS，這個應當就完全屬於配置類產品了。那我在平時的工作中也總結了幾個關於配置類產品的特點：
1。一般有配置項，所以不會是單獨存在的。
配置類的的產品一般都是為了達成系統中其他的一些功能點，或者配置另外一些網站等之類的東西所開發的模組，一般不會單獨存在。所以在做配置類產品的時候，我們做的時候不能簡簡單單的將自己目前所做的東西做完就好了。一定要聯動著看配置類產品以及它所配置的系統所更改東西的變化，大局觀更重，所要考慮的東西也更多。
2。思考的廣度不能停留在表面。
在做配置類產品的時候，對應的配置項可能不是特別複雜，但是產品經理在做的時候卻要慎重思考。比如在做CMS配置商城搶購的時候，前端需要所操作的頁面可能會比較簡單，使用者所要接收到的資訊也不會特別複雜，但是在進行後臺配置的時候，卻要將所有的資訊都考慮到。即便使用者只有1%的操作機率，那也要配置到這1%時候的操作結果。再如做角色劃分的時候，有些角色可能暫時用不到，但是為了整個系統未來的迭代等考慮要將其做進去。
3。角色處理時資料要做整理，流程要走通。
如果我們在做一套特別複雜的系統的時候，配置項往往都會決定著你的系統是否易用，因為可能不同的角色看到的會是不同的操作內容。而這些操作內容對於該角色來說都會是一個有機的整體，要讓他們覺得這個系統不突兀，所有的流程都要流暢，不覺得哪裡少點什麼，怪怪的。所以我們在進行配置設定的時候，不能簡單的做欄位的增刪，功能的顯示隱藏，要將系統的易用性放在重要的位置考慮。要在隱藏欄位與操作的同時將與之關聯的內容都進行配置。這樣才可以讓不同的角色使用時都會覺得自己用的是一套完整的系統。
關係類
關係類產品可以說和上面的幾種產品的分類定位不一樣。無論是配置類還是記錄類，都是透過其操作方式來劃分的。而關係類是透過功能來劃分的。只是因為自己最近在做關係類產品，所以拿出來單獨說一下。
市面上目前比較典型的關係類產品就是CRM了，許多公司透過自己的CRM來管理與客戶之間的關係。我們最近在做一個關於合作伙伴的管理系統，所涉及到的關係主要是商場與商場入駐店鋪之間的關係管理，設計一個關係管理產品的時候，思路是什麼樣的呢？
我覺得，既然是關係管理系統，那麼產品經理第一步要做的就是理清他們的關係，雖然可能一開始的關係會特別的複雜，而且難度更大的是可能有時候不止是兩者的關係，會有三種甚至多種角色的交叉關係，這個時候，開頭的工作一定會很艱難。
一般在做的時候，第一步要將這角色之間發生的所有交流都整理出來，在何種情境下這兩方會發生交流，然後在系統中會有哪些交流。這一步異常重要也十分複雜，需要產品經理極具耐心和細心。
其次，在將關係整理完畢後，需要整理出一條主線，即為什麼這兩者可以發生關係？之間怎麼傳遞的？傳遞的過程中會帶來哪些資訊？需要進行什麼樣的操作？比如一個電商的客戶管理系統，其主線就是客戶購買商品，所以這個就是它的主線。在資料內容方面，客戶購買完商品之後，我就有了客戶的購買資料，可以整理出客戶的RFM資料模型，可以為每個使用者進行畫像。在營銷方面，我可以根據客戶的購買的狀態及記錄進行相應的操作。可以透過其客單價復購率等為客戶進行VIP的評級，不同優惠的制定等等。透過這條主線進行發散，將整套系統的架子先搭起來。然後再填充上無法透過此流程進行關聯的內容，比如客戶資訊的錄入等等。
然後，再根據業務的重要性調整位置，填充具體內容。
最後，將整體流程跑一邊，看一下有沒有遺忘的流程，再和需求方業務方對接。
內部應用，外部應用
內部應用與外部應用說的主要是我們提供的服務物件。內部就指的是公司內部用的，而外部可能就會作為一個B端產品面向市場或者合作伙伴。
網站首頁的CMS時，第二部分的廣告條數量一開始是打算限制的，後臺對接的時候負責CMS的運營說我們不會傻到加100條的吧，網站的內容也是我需要負責的啊；在做品控系統的時候，需求對接的十分順暢，因為其實這些東西都是他們實實在在迫切要用到的，然後推到我們這邊來做。
所以在做內部應用的時候，相對來說壓力和挑戰都稍微少一些。一是本身就是自己的同事需求方面會盡可能的滿足你，二是既然公司要做這個系統就說明了的的確確公司需要這樣的一套系統。
然而外部系統卻不是這樣，因為這個時候我們面對的時候客戶，如果碰到一些本身自己需求就不明確的客戶，或者市場上有和我們在競爭的客戶，這個時候如何博得客戶的歡心，得到市場的認可也異常重要，與C端產品的研究使用者就有一拼了。
我建了一個產品小白交流群，點選下面的官方小卡片複製我的微訊號，新增進入交流群。我會給大家分享我收集整理的各種學習資料，組織大家一起做專案練習，幫助大家匹配一位學習夥伴互相監督學習，歡迎加入。
