做产品方案的时候,我们经常会走进死胡同或者跑错路,最后不论是开发还是市场,对结果都不满意,产品自然就成了背锅侠!但是往往我们出方案的时候,多想一些问题,或许结果就不一样,跟新人交流的时候,发现一些能力需要可以单独训练,有意识的去理解一些东西,长期积累就会有自己的一套解决问题的思路。
辨别真伪也就是老生常谈的真伪需求的能力,在产品经理的行业里,经常会进行需求的评审,需求的界定,看这个需求是否是真的有效
行业:外卖行业
案例:打包费审核的功能
功能出发点:解决商家乱设打包费的需求
解读:如果从这个角度来讲,打包费审核完全没必要,原因有
很显然,要在后台做一个打包费审核的功能,还需要让人专门处理此业务,对系统来说,是降低效率又不见得有效果的,所以,界定为伪需求。那么既然存在这样的问题,可替代方案如下:
辨别真伪的能力不仅仅体现在能辨别出来,更多的是能够用更灵活的方式来解决来自运营、消费者产生的问题,且不增加过多的额外工作。
合适定位的能力,这个说的有点虚,用通俗的话来讲,就是找个抄的对象。在国内想要做一个App有大量的抄袭模仿对象,各大知名厂商已经做了很多的研究,剩下的就是模仿和创新。能不能找到合适的模块去进行创新,这个就比较重要。
功能出发点:外卖行业的推荐商家,很多事按照细分的行业来做的,比如说美团跟饿了么的【必吃菜品】【品质联盟】这些,但是对消费者来说,这真的是我想要的选择么?
解读:从消费者的心理出发,我去找吃的,可能出于几点
其次还有可能
因此,从这类具有标示性的标签入手,会更有效果。此类功能类似于一点点的餐牌设计以及lofter的标签设计,将商家分配不同的标签跟消费者的消费场景对应上,交叉进行推荐,比如说一个商家有很多种口味,那对应的消费者人群也会多,消费者通过对应标签可以快速找到对应的商品,对消费者和商家都是互利的,我们经常会遇到一个外卖店铺有几十种餐品,找半天还是不知道吃啥。
(配个截图,此功能已实现,后续看数据情况,再做追踪)
顺便说一下,之前饿了么有个版本放大对餐品的显示,做餐品的推荐,后来又改回来,具体是什么因素,不确定,但那也是一种尝试。
出发点:那是很早以前的一个版本,因为不好用,所以就干脆做一个交互飞机稿,当时做的时候有以下几个因素:
解读:
当时荔枝FM算是国内比较早做电台的,同期出了喜马拉雅听,刚开始也没有荔枝FM那样火,但从交互上,主要由两个点:
对于合适的定位可以理解为:每个事物或许有自己固有的长相,但或许我们找到合适的逻辑后,只要抓住根本,那最后怎么玩,还是大家说了算,打破陈规,才更好玩。为什么音乐软件就一定要有那么大的播放界面;为什么订餐软件就一定要宣传店铺,不能是商品?
这个就老生常谈了,解决问题的能力体现在对系统的掌握程度和开发自由度两个层面,产品经理实质是提供解决方案的,任何需求到手后,我们需要分析如何快速解决该问题。
出发点:销售类岗位进行招聘时,都是一大批一大批的面试,一个人可能同时面试很多岗位,一个公司会面试很多个求职者,因此提高效率,对求职者和公司都是最大的需求
解决方案:排队叫号,跟银行排队一样,针对这个场景,我们梳理了核心的问题
针对以上四个问题,设计出如下流程(省略取号的环节,主要核心的流程是企业的发送通知循环以及面试后的符合不符合操作循环)
从流程图可以发现,核心逻辑并不复杂,解决了通知求职者来面试的需求以及对求职者进行评价需求即可;除此之外还可以做一些其他的功能,如求职者可以看到当前排队情况,根据实际情况进行简历投递,避免出现大量等待情况,可预知自己还要多久可以面试,在这时间内是否可以投递其他公司,进行多项选择;对于企业解决各种纸质简历分辨不清,电子档简历,电子记录每一个求职者和操作,可以清楚知道今天面试记录,电子档案,更清楚,提高双方的效率。
对于数据,很多人应该不会陌生,如何从杂乱的数据找到规律,怎么处理数据之间的关系?
最近在做小程序相关的项目,把腾讯的数据统计贴上来:
访问趋势类:
访问分布:
访问留存
访问页面:
产品经理从拿到需求开始就需要对需求进行分解,判断到底什么样的方案可以解决此问题,并结合当前系统的一些功能点,给出最佳的方案;在交互设计的时候是参考竞品还是微创新,就看实际业务需求;最后就是核心业务梳理,一个功能的核心业务是什么,还有哪些可以搭配让功能更完善的,考虑进去,做产品是一个分解、组合、删减、再组合的过程!