產品方案是簡單粗暴，亦或是精耕細作，還是根據具體維度（時間、成本、使用者、產品週期）做對應處理，需要各個產品經理的判斷。
在討論產品方案時，經常會遇到這樣的情景：
這個方案太複雜了，能不能簡單粗暴一點，大家都省事；這個方案太簡單了，照顧的面太小了，應該做的再精細化一點。那麼，作為乙個產品經理，該在兩者之間如何權衡、如何說服技術、ui哪？
舉例來說下這個問題，是要簡單粗暴的一刀切，還是精耕細作的做細分。
引導好評彈窗——精耕細作為了提高自家app在app store、各大android應用市場中的排名，各家都希望使用者對自家應用的好評越多越好，但是有沒有想過乙個問題：乙個差評的效果，需要多少個好評才能彌補？
如果想過這個問題，就應該知道，引導好評彈窗不應該在啟動app時就那麼隨意的一彈，而且呼叫系統預設彈窗的樣式，彈的那麼生硬；應該按照精耕細作的心態，尋找好的時機去彈，可見筆者之前的文章：《引導好評彈窗該怎麼玩？》
觀影後的評論——精耕細作現在買東西，無論是平台（天貓、京東等），還是商家都希望使用者能留下些評論（只是商家希望的是好評），而買電影票的平台也是這個思路，除了通過評論知道電影的可口程度、每個使用者的品位偏好外，還希望能增加朋友圈的分享概率。那麼問題來了，如果在乙個電影的放程式設計客棧映週期中，使用者刷了兩遍這個電影，那麼應該如何處理這問題？
首先，能被使用者二刷電影比例應該不高，同時二刷更能證明對電影的喜愛，那麼這樣的評論資料是否是更加有效地資料、是否能更加打動別人、是否能更飽含感情、是否能更容易觸發分享？那麼在平台已經成熟的情況下，是否可以通過優化評論來提高平台的活躍度和傳播率；如下截圖是某電影票平台在觀影結束後，開啟app是出現的引導評論介面，但是當我二刷後，此介面卻不會主動出現，但是我作為乙個使用者確實希望它能出現，方便我馬上寫下我二刷的感悟。另一張截圖為評論後在電影詳情頁的展示效果。
聊天順序——簡單粗暴現在很多即時通訊軟體都支援群聊，在群聊裡，大家爭先恐後、踴躍發言的時候，就涉及到發言順序的展示問題，是否要在所有人螢幕上都展現真實時間的聊天順序（即使用者傳送該訊息的時間/伺服器接收到這條訊息的時間）？如果這麼做，需要有個排序過程，無論排序工作在雲端還是在手機端進行，效率上都有不小開銷。此時需要考慮，順序是否真的重要，如果順序不對，會有什麼樣的影響？？
當產品經理在考慮這個問題的時候，會發現大部分情況下，使用者能自己知道哪句話是回覆給自己的，哪句不是回覆給自己的，所以順序的必要性不大；但是在筆者實際的使用中發現，在群內多人間交叉溝通的情況下，還是會出現誤解、答問不匹配的情況，但是這種小概率並不影響大部分的使用者體驗，同時考慮到成本問題，這個有損設計方案就是現在情程式設計客棧況下的最優解。
該部分可見筆者之前的文章：《有損設計：4個場景分析，到底什麼是適當的損度？》
電商付款收銀台——簡單粗暴如果讓讀者現在開發一款電商app，那麼在使用者講商品加入購物車，準備付款時，我們要提供那些付款方式給使用者？是否需要支援各種銀行卡支付？是否需要支援貨到付款？
相比在讀者回憶自己的付款經歷時會發現，貨到付款、各種銀行卡付款都很少用，不誇張的說，連門口買早點的都可以微信、支付寶支付了，你還要那麼多銀行卡付程式設計客棧款幹嘛哪？
你可能會說，反正sdk都是整合好的，為什麼不接入？技術上一鍋端了，但是，前段互動需要增加入口，回想下你買火車票的付款頁面，再回想下，你買外賣時的付款頁面，那個更流暢，顯而易見吧；同時這裡還有另乙個問題：時間成本，因為你增加了付款功能，測試是否要測試，如果測試的話，是否會延長上線時間，因為增加的測試時間，有可能就錯過一些時機。
以下為12306的付款頁面、大眾點評的付款頁面、得到的付款頁面，雖然使用者群體存在差別，但是隨著微信和支付寶的發展，這個網際網路基礎設施的付款環節的差別已經很小很小了。
行車記錄儀時間校準——簡單粗暴如果市場上已有了競品，那麼你的產品上市的時間就是越快越好，因為使用者可能習慣了你的競品，而不會再成為你的使用者了，硬體產品尤其如此，程式設計客棧因為硬體需要購買，使用者的遷移成本更加高。
那麼假設你在做一款夜視效果超級好的行車記錄儀，以夜視效果為最大賣點，其餘功能基本與行業頂尖水平持平，但是因為晶元平台的問題，導致在使用者設定系統時間時會高概率出現一些bug，導致機器不可用，如果要晶元廠商修復，那麼週期會很久，此時應該怎麼辦哪？
為了盡早上市與消費者見面，沒必要非得讓晶元商家修改，設定一套強制的開機方案，來解決這個問題，強制讓使用者用app連線行車記錄儀才能啟用該機器，然後同步手機app的時間進行修改，這樣可以有效避免bug的發生，同時手機端的時間大部分都是對的（其實可以認為是99.9%），或者說現在手機上的時間都是網路同步的，有人會去修改嗎？如果不會，那就可以了；通過這種一刀切的方案，縮短產品上市的時間，更早的搶占更多的使用者。但是這個強制連線的啟用流程必需設計的流程、有價值。
綜上，軟體初期，主流程通順，盡快占領使用者心智，簡單粗暴未嘗不可；軟體中後期，場景下的需求更加細化，滿足更多使用者，體驗更加細膩優美。有硬體，以硬體為準，因為硬體很難更新，賣出去就是賣出去了，莫非你真的要召回嗎？
所以，此時的軟體如何在硬體部分簡單粗暴地時候，做到軟體體驗上的精耕細作才是問題。
作者：代成龍，創業公司產品一枚，從**到智慧型硬體，再到車聯網，繼續產品設計之路。
本文標題: 產品方案應是簡單粗暴，還是精耕細作？
本文位址: /news/exp/62180.html
git最簡單直接粗爆與github教程
git 與 github 最簡單的使用 到github官網註冊github賬號 註冊好的頁面差不多這樣 點 start a project,第一次開啟,提示需要驗證你的郵箱,也就是註冊時的郵箱,驗證完郵箱後,新建乙個project 填好name 我這裡就叫origin好了,一定要點上下面的核取方塊 ...
「產品」 「服務」 「解決方案」
如題，是關於一些概念的文章。但常常會有同學對這三個含糊不清，甚至混淆。個人認為，是因為這些概念之間很多重疊的地方，但是又並沒有去細緻的研究它們的細微區別。我是從it的視角出發來研究這三者的區別，但是很顯然，這三個概念並不僅僅侷限於某乙個領域。所謂產品，通常是指乙個公司或者研究院開發出來的能夠提供一定...
產品售前解決方案結構
產品方案注重體現產品的亮點與應用場景，讓客戶知道本產品的利用價值以及哪些應用場景能契合到客戶的需求，其實客戶很少關心底層實現方式或者實現原理或者產品整體架構。另一方面，客戶會需要一些現代化的 有質感的冠名詞，比如雲計算 人工智慧 大資料 資料探勘代替以往的自動化 電子化 流程化 便捷等詞彙，很好的抓...