产品方案应是简单粗暴，还是精耕细作？

产品方案是简单粗暴，亦或是精耕细作，还是根据具体维度（时间、成本、用户、产品周期）做对应处理，需要各个产品经理的判断。

在讨论产品方案时，经常会遇到这样的情景：

• 这个方案太复杂了，能不能简单粗暴一点，大家都省事；

• 这个方案太简单了，照顾的面太小了，应该做的再精细化一点。

那么，作为一个产品经理，该在两者之间如何权衡、如何说服技术、UI哪？

举例来说下这个问题，是要简单粗暴的一刀切，还是精耕细作的做细分。

引导好评弹窗——精耕细作

为了提高自家APP在App Store、各大Android应用市场中的排名，各家都希望用户对自家应用的好评越多越好，但是有没有想过一个问题：一个差评的效果，需要多少个好评才能弥补？

如果想过这个问题，就应该知道，引导好评弹窗不应该在启动APP时就那么随意的一弹，而且调用系统默认弹窗的样式，弹的那么生硬；应该按照精耕细作的心态，寻找好的时机去弹，可见笔者之前的文章：《引导好评弹窗该怎么玩？》

观影后的评论——精耕细作

现在买东西，无论是平台（天猫、京东等），还是商家都希望用户能留下些评论（只是商家希望的是好评），而买电影票的平台也是这个思路，除了通过评论知道电影的可口程度、每个用户的品位偏好外，还希望能增加朋友圈的分享概率。那么问题来了，如果在一个电影的放映周期中，用户刷了两遍这个电影，那么应该如何处理这问题？

首先，能被用户二刷电影比例应该不高，同时二刷更能证明对电影的喜爱，那么这样的评论数据是否是更加有效地数据、是否能更加打动别人、是否能更饱含感情、是否能更容易触发分享？那么在平台已经成熟的情况下，是否可以通过优化评论来提高平台的活跃度和传播率；如下截图是某电影票平台在观影结束后，打开APP是出现的引导评论界面，但是当我二刷后，此界面却不会主动出现，但是我作为一个用户确实希望它能出现，方便我马上写下我二刷的感悟。另一张截图为评论后在电影详情页的展示效果。

聊天顺序——简单粗暴

现在很多即时通讯软件都支持群聊，在群聊里，大家争先恐后、踊跃发言的时候，就涉及到发言顺序的展示问题，是否要在所有人屏幕上都展现真实时间的聊天顺序（即用户发送该消息的时间/服务器接收到这条消息的时间）？如果这么做，需要有个排序过程，无论排序工作在云端还是在手机端进行，效率上都有不小开销。此时需要考虑，顺序是否真的重要，如果顺序不对，会有什么样的影响？？

当产品经理在考虑这个问题的时候，会发现大部分情况下，用户能自己知道哪句话是回复给自己的，哪句不是回复给自己的，所以顺序的必要性不大；但是在笔者实际的使用中发现，在群内多人间交叉沟通的情况下，还是会出现误解、答问不匹配的情况，但是这种小概率并不影响大部分的用户体验，同时考虑到成本问题，这个有损设计方案就是现在情况下的最优解。

该部分可见笔者之前的文章：《有损设计：4个场景分析，到底什么是适当的损度？》

电商付款收银台——简单粗暴

如果让读者现在开发一款电商APP，那么在用户讲商品加入购物车，准备付款时，我们要提供那些付款方式给用户？是否需要支持各种银行卡支付？是否需要支持货到付款？

相比在读者回忆自己的付款经历时会发现，货到付款、各种银行卡付款都很少用，不夸张的说，连门口买早点的都可以微信、支付宝支付了，你还要那么多银行卡付款干嘛哪？

你可能会说，反正SDK都是集成好的，为什么不接入？技术上一锅端了，但是，前段交互需要增加入口，回想下你买火车票的付款页面，再回想下，你买外卖时的付款页面，那个更流畅，显而易见吧；同时这里还有另一个问题：时间成本，因为你增加了付款功能，测试是否要测试，如果测试的话，是否会延长上线时间，因为增加的测试时间，有可能就错过一些时机。

以下为12306的付款页面、大众点评的付款页面、得到的付款页面，虽然用户群体存在差别，但是随着微信和支付宝的发展，这个互联网基础设施的付款环节的差别已经很小很小了。

行车记录仪时间校准——简单粗暴

如果市场上已有了竞品，那么你的产品上市的时间就是越快越好，因为用户可能习惯了你的竞品，而不会再成为你的用户了，硬件产品尤其如此，因为硬件需要购买，用户的迁移成本更加高。

那么假设你在做一款夜视效果超级好的行车记录仪，以夜视效果为最大卖点，其余功能基本与行业顶尖水平持平，但是因为芯片平台的问题，导致在用户设置系统时间时会高概率出现一些bug，导致机器不可用，如果要芯片厂商修复，那么周期会很久，此时应该怎么办哪？

为了尽早上市与消费者见面，没必要非得让芯片商家修改，设置一套强制的开机方案，来解决这个问题，强制让用户用APP连接行车记录仪才能激活该机器，然后同步手机APP的时间进行修改，这样可以有效避免bug的发生，同时手机端的时间大部分都是对的（其实可以认为是99.9%），或者说现在手机上的时间都是网络同步的，有人会去修改吗？如果不会，那就可以了；通过这种一刀切的方案，缩短产品上市的时间，更早的抢占更多的用户。但是这个强制连接的激活流程必需设计的流程、有价值。

综上，

• 软件初期，主流程通顺，尽快占领用户心智，简单粗暴未尝不可；

• 软件中后期，场景下的需求更加细化，满足更多用户，体验更加细腻优美。

有硬件，以硬件为准，因为硬件很难更新，卖出去就是卖出去了，莫非你真的要召回吗？

所以，此时的软件如何在硬件部分简单粗暴地时候，做到软件体验上的精耕细作才是问题。

产品方案是简单粗暴，亦或是精耕细作，还是根据具体维度（时间、成本、用户、产品周期）做对应处理，需要各个产品经理的判断，以上一点整理，供参考。