产品方案应是简单粗暴,还是精耕细作?.docVIP

产品方案应是简单粗暴,还是精耕细作?.doc

  1. 1、本文档共14页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
产品方案应是简单粗暴,还是精耕细作?

产品方案应是简单粗暴,还是精耕细作?   产品方案是简单粗暴,亦或是精耕细作,还是根据具体维度(时间、成本、用户、产品周期)做对应处理,需要各个产品经理的判断。      在讨论产品方案时,经常会遇到这样的情景:   这个方案太复杂了,能不能简单粗暴一点,大家都省事;   这个方案太简单了,照顾的面太小了,应该做的再精细化一点。   那么,作为一个产品经理,该在两者之间如何权衡、如何说服技术、UI哪?   举例来说下这个问题,是要简单粗暴的一刀切,还是精耕细作的做细分。   引导好评弹窗——精耕细作   为了提高自家APP在App Store、各大Android应用市场中的排名,各家都希望用户对自家应用的好评越多越好,但是有没有想过一个问题:一个差评的效果,需要多少个好评才能弥补?   如果想过这个问题,就应该知道,引导好评弹窗不应该在启动APP时就那么随意的一弹,而且调用系统默认弹窗的样式,弹的那么生硬;应该按照精耕细作的心态,寻找好的时机去弹,可见笔者之前的文章:《引导好评弹窗该怎么玩?》   观影后的评论——精耕细作   现在买东西,无论是平台(天猫、京东等),还是商家都希望用户能留下些评论(只是商家希望的是好评),而买电影票的平台也是这个思路,除了通过评论知道电影的可口程度、每个用户的品位偏好外,还希望能增加朋友圈的分享概率。那么问题来了,如果在一个电影的放映周期中,用户刷了两遍这个电影,那么应该如何处理这问题?   首先,能被用户二刷电影比例应该不高,同时二刷更能证明对电影的喜爱,那么这样的评论数据是否是更加有效地数据、是否能更加打动别人、是否能更饱含感情、是否能更容易触发分享?那么在平台已经成熟的情况下,是否可以通过优化评论来提高平台的活跃度和传播率;如下截图是某电影票平台在观影结束后,打开APP是出现的引导评论界面,但是当我二刷后,此界面却不会主动出现,但是我作为一个用户确实希望它能出现,方便我马上写下我二刷的感悟。另一张截图为评论后在电影详情页的展示效果。         聊天顺序——简单粗暴   现在很多即时通讯软件都支持群聊,在群聊里,大家争先恐后、踊跃发言的时候,就涉及到发言顺序的展示问题,是否要在所有人屏幕上都展现真实时间的聊天顺序(即用户发送该消息的时间/服务器接收到这条消息的时间)?如果这么做,需要有个排序过程,无论排序工作在云端还是在手机端进行,效率上都有不小开销。此时需要考虑,顺序是否真的重要,如果顺序不对,会有什么样的影响??   当产品经理在考虑这个问题的时候,会发现大部分情况下,用户能自己知道哪句话是回复给自己的,哪句不是回复给自己的,所以顺序的必要性不大;但是在笔者实际的使用中发现,在群内多人间交叉沟通的情况下,还是会出现误解、答问不匹配的情况,但是这种小概率并不影响大部分的用户体验,同时考虑到成本问题,这个有损设计方案就是现在情况下的最优解。   该部分可见笔者之前的文章:《有损设计:4个场景分析,到底什么是适当的损度?》      电商付款收银台——简单粗暴   如果让读者现在开发一款电商APP,那么在用户讲商品加入购物车,准备付款时,我们要提供那些付款方式给用户?是否需要支持各种银行卡支付?是否需要支持货到付款?   相比在读者回忆自己的付款经历时会发现,货到付款、各种银行卡付款都很少用,不夸张的说,连门口买早点的都可以微信、支付宝支付了,你还要那么多银行卡付款干嘛哪?   你可能会说,反正SDK都是集成好的,为什么不接入?技术上一锅端了,但是,前段交互需要增加入口,回想下你买火车票的付款页面,再回想下,你买外卖时的付款页面,那个更流畅,显而易见吧;同时这里还有另一个问题:时间成本,因为你增加了付款功能,测试是否要测试,如果测试的话,是否会延长上线时间,因为增加的测试时间,有可能就错过一些时机。   以下为12306的付款页面、大众点评的付款页面、得到的付款页面,虽然用户群体存在差别,但是随着微信和支付宝的发展,这个互联网基础设施的付款环节的差别已经很小很小了。            行车记录仪时间校准——简单粗暴   如果市场上已有了竞品,那么你的产品上市的时间就是越快越好,因为用户可能习惯了你的竞品,而不会再成为你的用户了,硬件产品尤其如此,因为硬件需要购买,用户的迁移成本更加高。   那么假设你在做一款夜视效果超级好的行车记录仪,以夜视效果为最大卖点,其余功能基本与行业顶尖水平持平,但是因为芯片平台的问题,导致在用户设置系统时间时会高概率出现一些bug,导致机器不可用,如果要芯片厂商修复,那么周期会很久,此时应该怎么办哪?   为了尽早上市与消费者见面,没必要非得让芯片商家修改,设置一套强制的开机方案,来解决这个问题,强制让用户用APP连接行车记录仪才能激活该机器,然后同步手

文档评论(0)

haowendangqw + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档