遇到无竞品可借鉴的情况该如何设计产品？首先做产品不是基于竞品的设计，做产品的各个维度也不是根据竞品的思路去打造的。 产品从0到1的过程需要根据自己的产品定位，用户定位、尤其是初期核心用户的定位，分析用户，产品的出发点是什么，是为了解决用户的什么问题，所谓从0开始，就是市面上目前还没有一个产品可以解决这个问题，前期一般需要做各种形式的用户调查，不管是问卷调查还是走访，都是需要切实的接触到你的用户，了解他们的需求是否是真实存在的。而你们的产品就是要满足这些目标用户的需求，解决用户的问题，这样产品诞生的第一步也就迈出去了。 第二步就需要围绕用户的需求规划产品了。为自己的产品定位，设计产品每个模块的功能，设置不同功能的关联关系，即根据确定的业务流，搭建产品的功能框架。梳理完整的产品业务流，赢利点在哪？产品的核心竞争力在哪？ 判断一个产品用户体验好与坏？ 一、使用性能，也就是通常说的响应速度，这个最重要，给个指令无响应何来体验？ 1、首页加载速度，这时给人的第一印象，也是看脸面的时候； 2、界面交互速度，打开频道页响应速度； 3、高频操作的体验，（例如，点赞生效的反馈，是无需同步与数据库交互的） 4、第三方时效保证（例如，运营商的短信到达时长、现金提现到达时长等） 二、使用难易度，页面打开后，是否存在使用障碍？ 1、不给帮助不给提示，路边随便找个大妈大叔就应该可以使用（打车软件、团购软件，超市结账）； 2、生僻名词，犹豫时长，对字段名字 需要百度才知道，或者问了朋友才知道（稍专业点的产品，可以忍受相对专业的词汇）； 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%。 真相六：留存率与推送的数量没有关系 很多运营商都很会很关心，究竟推送数量要发送多少才能最有效地保证用户留存率。而实际数据表明，用户留存率与推送发送的数量并没有太大关系，重要的不是发送几次，而是发送什么内容。 产品在苹果App Store上架过程中都遇到过哪些坑1：检测更新 2：和系统接近的图标效果 生活日历之前标志用了一年多，直到苹果推出通知中心以后，因为标志和他们像就被打回了，改了很多版本，颜色图形各种改都不给过，最后直接换了一个标志；另外app推荐也不能用，一般用服务器控制，通过后再上；安卓的字眼不能有。 3：使用QQ登录会进入引导下载QQ页面，结果被苹果退回审核 用了QQ第三方登陆，如果用户没有安装QQ的话，使用QQ登录会进入引导下载QQ页面，结果被苹果退回审核。糗百有这个问题，在没安装正常版本QQ情况下，不提供web qq登录，但是一直顺利上线。 4：广告原因导致被拒 使用了里面有广告代码，但是没有显示广告，可能因为调用了它的IDFA的相关东西。就算没广告的展现，但是苹果也发现你们调用了，就会说你们有广告。 接着说友盟的问题：友盟为了逃避苹果的审核，在后台默认做了一个淘宝的全屏广告，不过在3月之前都可以过，但在3月之后，苹果也要拒，因为很多产品和淘宝的广告不符合。比如我是糗百，弹出一个淘宝广告，苹果也会拒绝。所以一般有两种做法： ● 采用友盟的无IDFA的sdk，不过无IDFA的sdk对统计会有误差。 5：出现第三方操作系统的名字或图标 你的app截图也最好不用android手机壳子，android的也不要用iphone状态栏。在各个市场，都不允许出现对方系统的东西，我们android之前偷懒，用了iOS宣传图，也被android市场拒绝过，因为状态栏是iOS的。 6：注册登录，性别和头像非必填 7：软硬件结合的产品，一定要拍摄视频或者寄送硬件给苹果检测 8：界面太丑，宣传太过，跟风明显会被拒 界面太丑的情况也有被拒绝过，产品没新意也是被拒的一个原因。宣传图片过度，也会被拒。 9：内容型 app遇到版权问题 10：支付、文案等问题导致被拒 酒店后台支付系统考虑哪几方面？ 设计后台系统基本按照以下几个方面考虑：数据、流程、审计风控 数据：交易流水、交易状态、交易订单 交易流水：流水ID、商户订单号、第三方交易流水号、金额、发生时间、商品信息、进出帐类型 交易状态集：基本态（未支付、已支付、已退款）、可能的特殊态（已预付、以补充支付、交易作废、部分退款） 交易订单：订单总金额、应收金额、实收金额、商品总价、优惠金额（市场补贴） 计算规则 流程： 预付、补充支付、退款 预付：用户预订酒店房间缴纳部分定金，预付后封锁库存 补充支付：订单服务完成，最终支付的总金额>预付金额，需要补充支付，补充支付后交易完成 退款：自动退款，当交易未完成或重复支付等情况则根据退款逻辑自动触发退款，手动退款，当产生客服人工介入处理、或异常情况则需要容错处理人工退款 审计风控： 对账： 系统交易记录自洽，需要所有支付渠道金额加和等于订单的服务应收金额， 第三方对账：保证第三方（支付宝微信等）的交易流水与系统内的流水完全匹配 市场补贴以及内部会员的对账，保证交易记录的实际发生费用与虚拟账户系统、营销系统记录的数据一致 税率：单笔或多笔交易其中可能涉及个人所得税、以及交易税等 风控：要考虑支付产生的风险规避、交易失败的处理方式，重复支付的处理方式，系统权限控制。 其中：交易与库存锁定一定是统一的事故处理——保证交易完成才能执行库存锁定，避免造成公司财产损失（公司亏钱，你还有钱拿么？） 权限控制，系统的手动操作扣，调账操作一定是高级的财务或运营人员。 重复支付：保证用户单次支付成功，避免用户财产损失（用户亏钱，那一定会投诉） 对于避免重复支付的解决方案给个简单方案分享一下 ： 注： 1、方案一和方案二 单独就可以避免重复支付，也可以同时生效 2、方案一有一个弊端就是如果同一个订单，可以被支付多次，例如100元的订单，微信先支付50然后 有支付50 则需要取消方案一，保留方案二 3、因为支付宝和微信都有避免重复支付机制“同一个商户订单号不可以被支付多次”，所以一般的简单产品支付，方案一就可以解决。  如何让用户愿意上传自己的头像1. 最初级的当然是激励。让上传真实头像的用户在社交圈内形成优势。 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） 是什么愿意让用户分享分享本质是一种表达。 1、宣告存在 - 如果外界都不知道自己的存在，实际上就等于不存在了 2、寻找同类 - 通过群体共存获得安全感、提高生存概率 3、表现自己的特殊 - “不一样”是“我”存在的重要表现 4、提供价值 - 让自己在群体中是有用的，扩大影响力 5、博取关注 - 如果没法通过对外提供价值获得关注，可能会反过来用一些自己的遭遇吸引别人关心 6、寻求帮助 - 关乎自己生存 7、危机告警 - 关乎群体生存 汽配件非标品庞大的SKU要怎么建立汽车配件粗分有两类：保养件(比如机油，三滤，雨刮器等)，维修件(钣金，发动机，大灯等)保养件：其实你不用特别的设计，因为博世啊，壳牌啊，米其林啊都已经帮你做好了SKU的数据结构和管理，并且还是灰常成熟的，取之就好； 维修件：这是一个最麻烦的，一辆20万左右车，拆散了，约3W零部件，全品牌车型配件约16亿配件。这个SKU的建立是硬功夫。有一个核心点，不管是什么品牌，什么车型的车子，它身上的每个配件都有一个编码，这个编码俗称OE码，这是公开的秘密数据。每条OE码数据可以解析出276个信息，这些信息足以支撑你建立完整的SKU基础信息； 移动端产品有三个重：重场景、重碎片化、重速度
|
|
|
