产品经理经常遇到的诸多问题一Word文档下载推荐.docx

产品经理经常遇到的诸多问题一Word文档下载推荐.docx

《产品经理经常遇到的诸多问题一Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《产品经理经常遇到的诸多问题一Word文档下载推荐.docx（5页珍藏版）》请在冰豆网上搜索。

1、不给帮助不给提示，路边随便找个大妈大叔就应该可以使用（打车软件、团购软件，超市结账）；

2、生僻名词，犹豫时长，对字段名字需要XX才知道，或者问了朋友才知道（稍专业点的产品，可以忍受相对专业的词汇）；

3、所见即所得，例如点一个按钮就知道是干嘛（new.PMcaff上方的“+发布”的示意就非常的明确，相信没有产品经理不了解吧）三、使用舒服度，用着舒服吗？

1、关乎配色是否符合大众审美，或者具有产品辨识度的统一色；

2、线框搭配比例，是否优美，例如通常说的黄金比例；

3、视线与操作路径的关系，这个是通用需要考虑旳，不管是移动端APP，还是PC端ERP,或者是手持设备，查看操作是否连贯，一致。

四、你的产品简单吗？

简单可依赖（特别是对于新产品）1、简单会减少学习成本；

2、简单会印象深刻；

3、复杂的事情简单化，这个大家应该都认同，不认同的应该是没有对一个功能经过精雕细琢，当你真正把一件复杂的事情变简单的时候，你是非常有成就感的，可能你就是制定流程，树立行业标杆的人了。

产品经理分析产品的思路

nABC法Needs:

需求N1，用户最基本的需求是什么？

N2，市场有多大？

N3，行业链如何构成？

N4，行业发展趋势如何？

N5，扩充的需求有哪些？

Approach：

解决方案A1，解决方案如何构成？

A2，需求优先级如何定义？

A3，技术可行性如何？

A4，有无政策，法规风险？

A5，版本如何规划，发布路线图如何定义？

A6，各个版本的营销思路如何？

重心是什么？

Benefits：

盈利模式B1，盈利模式如何？

B2，盈利期望（时间，数目）；

B3，各版本的盈利预计；

B4，投入产出评估；

Competition：

竞争分析C1，行业链竞争，被替代可能性如何？

C2，重点竞争对手有哪些？

C3，各个阶段，各个版本的目标竞争对手是谁？

C4，各个阶段对重点对手SWOT分析，USED策略产品经理如何度过产品需求的空档期1.看数据，数据分析做产品优化以及迭代准备；

2.做客服，了解用户心声，了解用户对产品功能的反馈和建议，提取关键点，也为迭代优化做准备；

3.看竞品，了解行业动态；

了解竞品是否推出新功能，为什么推出某新功能，能否适用自己产品；

了解整个行业的大方向，判断自己产品是否偏离轨道；

4.项目跟进，跟设计和开发沟通，能否如期完成，是否遇到困难，沟通调整方案（这点你已描述）5.跟运营了解产品上线后的运营方案，协作优化运营策略等；

6.开发后期可以做下黑盒测试工作，看看开发初期效果；

7.根据自身能力的不足以及自己的兴趣爱好，补充一些相关知识。

有哪些引导用户接受Push的好办法关于推送的真相真相一：

用户厌烦的并不是推送功能本身针对如何看待推送功能这一问题，对1万名用户进行了问卷调查，结果表明80%的用户表示不会拒绝推送功能。

各个年龄段方面没有太大的差别，但女性用户更容易受个人兴趣和心情影响。

真相二：

推送同样会带来用户卸载风险23%的用户有因为系统推送而卸载APP的经历。

这也就是说，推送功能同样会成为用户卸载的一个契机。

调查结果显示越年轻的用户对推送的抵抗倾向越小，而40岁左右的女性对推送最为包容。

原因是这一年龄层的女性多为主妇，比起其他类型的人群她们更需要各种不同渠道的信息和情报。

真相三：

35%～50%的用户允许系统发送推送APP初次启动的时候，有35%～50%的用户允许系统发送推送，而其中“媒体”的承认度最高、平均50%，“游戏”则比较低、平均35%，娱乐为45%、运动为48%真相四：

推送功能ON的用户会经常使用该APP推送功能ON的用户经常使用该APP的倾向更为明显，而在游戏类APP中，推送功能ON的用户月平均启动次数为27次，而推送功能OFF的用户月平均启动次数万恶20次。

真相五：

推送使得用户留存率提升无论推送功能开启与否APP启动率都相差无几的“媒体”类APP中，仍然提高了用户留存率。

6个月后“新闻”类APP中，推送功能ON的用户留存率为50%，推送功能OFF的用户留存率为31%。

而“游戏”类APP上，这两个数字分别为14%和9%。

真相六：

留存率与推送的数量没有关系很多运营商都很会很关心，究竟推送数量要发送多少才能最有效地保证用户留存率。

而实际数据表明，用户留存率与推送发送的数量并没有太大关系，重要的不是发送几次，而是发送什么内容。

产品在苹果AppStore上架过程中都遇到过哪些坑1：

检测更新2：

和系统接近的图标效果生活日历之前标志用了一年多，直到苹果推出通知中心以后，因为标志和他们像就被打回了，改了很多版本，颜色图形各种改都不给过，最后直接换了一个标志；

另外app推荐也不能用，一般用服务器控制，通过后再上；

安卓的字眼不能有。

3：

使用QQ登录会进入引导下载QQ页面，结果被苹果退回审核用了QQ第三方登陆，如果用户没有安装QQ的话，使用QQ登录会进入引导下载QQ页面，结果被苹果退回审核。

糗百有这个问题，在没安装正常版本QQ情况下，不提供webqq登录，但是一直顺利上线。

4：

广告原因导致被拒使用了里面有广告代码，但是没有显示广告，可能因为调用了它的IDFA的相关东西。

就算没广告的展现，但是苹果也发现你们调用了，就会说你们有广告。

接着说友盟的问题：

友盟为了逃避苹果的审核，在后台默认做了一个淘宝的全屏广告，不过在3月之前都可以过，但在3月之后，苹果也要拒，因为很多产品和淘宝的广告不符合。

比如我是糗百，弹出一个淘宝广告，苹果也会拒绝。

所以一般有两种做法：

●采用友盟的无IDFA的sdk，不过无IDFA的sdk对统计会有误差。

●自己做个banner广告，审核过了后台修改参数，隐藏。

5：

出现第三方操作系统的名字或图标你的app截图也最好不用android手机壳子，android的也不要用iphone状态栏。

在各个市场，都不允许出现对方系统的东西，我们android之前偷懒，用了iOS宣传图，也被android市场拒绝过，因为状态栏是iOS的。

6：

注册登录，性别和头像非必填7：

软硬件结合的产品，一定要拍摄视频或者寄送硬件给苹果检测8：

界面太丑，宣传太过，跟风明显会被拒界面太丑的情况也有被拒绝过，产品没新意也是被拒的一个原因。

宣传图片过度，也会被拒。

9：

内容型app遇到版权问题10：

支付、文案等问题导致被拒酒店后台支付系统考虑哪几方面？

设计后台系统基本按照以下几个方面考虑：

数据、流程、审计风控数据：

交易流水、交易状态、交易订单交易流水：

流水ID、商户订单号、第三方交易流水号、金额、发生时间、商品信息、进出帐类型交易状态集：

基本态（未支付、已支付、已退款）、可能的特殊态（已预付、以补充支付、交易作废、部分退款）交易订单：

订单总金额、应收金额、实收金额、商品总价、优惠金额（市场补贴）计算规则流程：

预付、补充支付、退款预付：

用户预订酒店房间缴纳部分定金，预付后封锁库存补充支付：

订单服务完成，最终支付的总金额>

预付金额，需要补充支付，补充支付后交易完成退款：

自动退款，当交易未完成或重复支付等情况则根据退款逻辑自动触发退款，手动退款，当产生客服人工介入处理、或异常情况则需要容错处理人工退款审计风控：

对账：

系统交易记录自洽，需要所有支付渠道金额加和等于订单的服务应收金额，第三方对账：

保证第三方（支付宝微信等）的交易流水与系统内的流水完全匹配市场补贴以及内部会员的对账，保证交易记录的实际发生费用与虚拟账户系统、营销系统记录的数据一致税率：

单笔或多笔交易其中可能涉及个人所得税、以及交易税等风控：

要考虑支付产生的风险规避、交易失败的处理方式，重复支付的处理方式，系统权限控制。

其中：

交易与库存锁定一定是统一的事故处理——保证交易完成才能执行库存锁定，避免造成公司财产损失（公司亏钱，你还有钱拿么？

）权限控制，系统的手动操作扣，调账操作一定是高级的财务或运营人员。

重复支付：

保证用户单次支付成功，避免用户财产损失（用户亏钱，那一定会投诉）对于避免重复支付的解决方案给个简单方案分享一下：

注：

1、方案一和方案二单独就可以避免重复支付，也可以同时生效2、方案一有一个弊端就是如果同一个订单，可以被支付多次，例如100元的订单，微信先支付50然后有支付50则需要取消方案一，保留方案二

3、因为支付宝和微信都有避免重复支付机制“同一个商户订单号不可以被支付多次”，所以一般的简单产品支付，方案一就可以解决。

如何让用户愿意上传自己的头像1.最初级的当然是激励。

让上传真实头像的用户在社交圈内形成优势。

a.通过产品策划，让社交环境自身对上传真实头像的用户形成奖励。

比如婚恋类APP，未上传真实头像用户肯定得不到其它用户信任，得不到网站算法推荐，参加不了网站活动等等。

b.给予直接奖励，物质的或者虚拟的。

2.头像美化。

传上去就美美的，嗯。

把传头像和美化头像变成一种“玩”。

3.运营一些传头像的活动。

除了给奖励名还可以加入比如：

比酒窝、比脸长，各种无节操，把“头像一定要美才能传”从你APP的社交圈里弱化掉。

建立[用户画像]的标签的常用几个维度a.自然特征OR基本属性：

性别、年龄、体型、职业、星座、教育程度等b.消费特征OR购买能力：

婚否、收入、车、房、孩子、购物类型、品牌偏好、信用水平、购买周期等c.社会特征OR行为特征：

婚姻状况、家庭构成、社交偏好、信息渠道等d.兴趣特征OR心理特征：

兴趣爱好、使用APP行为、浏览收藏内容、互动内容等

两件商品分属不同的商户，如何结算

用户将分属于两个商户的商品放进购物车中，（商品a：

40元，属于商户A;

商品b：

60元，属于商户B），点击购买，用户付款80现金，10元代金券，10个积分；

用户付款成功后，那么用户支付的80现金+10元代金券+10个积分，我如何给商户A和商户B结算券是平台代商户发的，积分是统一的积分，我们和合作商户签订积分合同，给商户一定的发放积分的额度（用户购买某个商户的商品，会返还一定数额的积分给他，在支付其它订单时，可以抵扣订单金额）拆分子订单，结算就是按商品现在销售价格占总价的比例。

直接“按比例”。

这个例子中，总额40＋60=100现金给A商品：

80*（40/100）代金卷A商品：

10*（40/100）积分A商品：

10*（40/100）当然非整数的话，结算也是按比例，不过在结算总额的时候，可能存在末尾数字取舍进退位等问题比如附加例子中：

现金给A商品（此时A价格43.5元，B价格56.5元，总共100元）：

80*（43.5／100）是什么愿意让用户分享

分享本质是一种表达。

所有表达本质是为了“我”的生存利益，分享是因为“与我有关”“对我有利”；

而“与我有关”“对我有利”的最佳证明是“外界的关注和反馈”；

当我们在问“用户为什么分享”的时候，