大干货，找工作 的朋友，这一节讲讲业务

此处10大大问题帮助你理清业务

一.需求分析-背景

这是一个很大的话题，现在都讲不好这个，所有东西源于这个1,1生2,2生3

做产品有个很奇葩的感觉，就是上一段时间做出来的东西，自己以为惊为天人，回头想想也就那么回事-自己

1. 分析需求目的
   当我们接到一个产品需求时，首先应该搞清楚这个需求是什么，为什么有这个需求。可以从以下5个方面展开分析。

需求是什么
为什么提这个需求
需求的受众人群是谁？他们都有什么特点
在什么场景下需要到此需求
如何提炼出更精准的需求，需求的目的

EG：放出自己的业务例子

需求是什么	为什么提需求	使用人是谁	使用场景	如何提炼需求
一批优惠券想要自动发放，作为会员福利；作为商家投放平台	为了自动发放优惠券，自动维护	商户+运营	商户创建优惠券+审核发放优惠券+补充优惠券+核销优惠券	将发放核销流程迁移到系统
私域流量用户推送、用户标签	更加精细化的运营、项目的话语权	运营	不同标签的用户精细化运营+打标签	数据分散在各个系统，做一个整合的数据平台
配置活动和app内容资源位	活动上线资源位置	运营	配置不同类型的活动	配置活动和资源位

目标用户他们的痛点是怎么样
【1】门店销售增长瓶颈 : 怎么提高门店竞争力和提升销售业绩?
【2】缺少对店内顾客的了解 : 顾客特征是什么？怎么实现更精准的营销？
【3】缺少有效的分析预测 : 怎么优化资源配置，提高运作效率?

之前通过电梯广告发券，触达率低	在后台发券，触达租户
线下发券	发券的流程迁移到线上
数据没有统一	私欲流量帮助更好的运营用户
每个活动单独写网页	提高活动配置效率

画外音：这个MARKDOWN语法还好用

二.使用场景

应该怎么说呢，需求是从场景当中抽象出来的，而场景也是需求的进一步扩展，2者不离不弃

这里简述了大概的对比场景，具体的场景围绕需求铺开

系统	系统上线前	系统上线后
优惠券后台	上线前，优惠券需要手工添加和维护，数量增加减少容易混淆，不易管理	优惠券在系统，增删改查不易混淆，容易管理

衍生了某某人为了什么做了什么事情

某人	特征	痛点

三.主要流程梳理

1.先分析一个优惠券最主要的逻辑

不考虑任何异常情况，其实就是创建—发放—领取—核销

2.扩充流程，绘制泳道图

1.登陆流程 2.创建商户 3. 修改账号密码 4. 新增优惠券 5.审核优惠券 6.补券流程7.核销流程
补充异常流：1新增商户账号重复，需要重新上传账号；2创建商户账号失败，弹框提醒管理员 3 审批拨回，需要商户修改后上传信息

优惠券流程梳理

四.比较复杂/成功/精彩的功能

背景：
当时系统里都是异业券，需要设置租房券
订单和支付系统在印度，需要同步状态，怎么处理同步的状态
日本业务方对租房优惠券的规则条件的设置和我们自己的理解不太一样全部优惠是指无论租客在一个月的何时入住，优惠券的额度是一个整月的额度 ；部分优惠是根据租客在当月的入住时长，相应减少优惠券的额度（百分比）
行动：
1.新建一个入口
单独设置一个renter的角色和renter的权限，renter权限可以可以付给管理员
2.同步3方状态
针对印度订单创建但是同步失败的情况，做一个异常状态处理。在状态栏中加入一种状态“创建中”，如果有状态为创建中，则站内信提醒商户联系我们
3.核对字段
不同的含义：全额优惠&部分优惠 短租、长租 3次沟通确认
结果：
11月上线了租房优惠券，租房的转化提升了？%

五.觉得做的失败的功能？

万能公式—需求揣摩+原因分析+解决方法

做了很多功能，例如商户新闻、优惠券在前端的显示、节庆日历
用这两项功能的商户只有1/100
商家使用率不高
所以最后去除了这些功能，只保留了核心的几项功能
原因：没有把握好核心需求，划分好优先级
不足：发放的不够精准
【背景】像曾经有一位25岁单身的女生，3天一直看药品保健的券，推送，后来知道他妈妈生病了
【原因】比如仅仅凭借用户的浏览的数据，推断是否需要一张优惠券
【方案】
获取用户更多纬度的信息，
对用户的历史记录做一个梳理
运用更好的算法

六.竞品分析

以前以为只是C端，现在B端也在不停的提

窃以为，竞品分析PPT主要是分3部分吧
竞品的简介
竞品的一些主要特征
竞品和自己相似点的对比
（下次直接来一版导购的B端产品对比）

七.对后台未来的规划（降本提效）

把核销放进系统里
商家的转化率监控
标签动态赋能
培养高潜力的头部商家
为商家发现问题、获得资源、实现其业务成长
出售资源位

八.数据分析

数据整合
*为了说明，以下数据纯属编造
（累计）V1量大，V2 领取率高

数量虚拟

优惠券后台
对商户——商户好评 商户数量增加
对平台——V2会员转化率提升 商户曝光后的转化率提升到5% 左右

CRM
用户留存率
有时用流失率可能更恰当
（CRM 系统上线之前，用户的次日留存率为 10%，上线后次日留存率为 14%）
用户人数 10万间房源 2万间
CMS
活动曝光数量由每个月只能配置3个增加到配置12个
领取了44530张优惠券，使用13200+张券，平均使用率29.6%

九.和开发起冲突怎么办

【结果】站在技术的角度思考，他们需要的无非是：
产品有效果，可以作为晋升的依据
阶段的需求适量，不要天天加班
不要经常变更需求，重复开发
冲突的根源都是信任问题，日常互动增进彼此互信
【根源】一切人际关系的问题都是信任问题，所以解决方案也很简单，就是通过日常的一件件小事，增强彼此之间的信任，然后一切都会迎刃而解：
1.需求评审开发提问题或者挑战你的需求，不要着急反驳，可以解答的当场解答，不可以解答的，记录下来，感谢对方的建议，完善后再二次评审。
2.需求上线后总结数据效果，发出给所有参与的开发，即使数据效果不佳，也要让原因分析和后续优化让大家知道，让开发觉得被尊重。
3.控制每个迭代的需求数量，避免开发长时间过度加班，如果老板强压需求，一定要据理力争。
4.如果某个迭代需求太多无法避免，后面一个迭代一定适度减少需求。
需求推进的关键时期，考虑将座位搬到开发同学附近，形成“团队作战”的感觉

十.如何降本增效-优先级

当接到一个需求后，除了对需求进行分析转化为产品方案之外，我们也要评估需求的价值及如何降本增效

1. 评估需求的价值

需求的价值包含两个方面——评估需求的可行性 ；评估需求的成本，通过评估这两个方面我们可以确定这个需求公司值不值的做，如果接到需求就去做会导致公司核心研发能力无法聚焦，竞争优势下降。或因需求的成本不可把控导致公司成本投入过大。

作为产品经理除了设计产品方案，把控产品质量和工期之外我们也要对公司的发展战略和方向有一个清晰的认知。当在商务手中接到需求之后，我们应评估该需求是否和公司战略方向一致？评估该需求的研发难点是否可以攻克是否需要和其他公司建立合作关系，防止在研发中发现该问题导致研发返工或者工期延误。

2. 评估需求的优先级

需求值不值做
A类需求和B类需求都是可行的，属于有效需求。

有效需求评估

3. 评估需求的成本

把控需求的研发成本。

当评估的需求是B类型需求时，我们就要对需求的成本进行评估。此时将召开项目立项会，召集相关人员评估需求的研发成本。成本主要包含研发难点，通过评估研发难点可以得到我们要解决这个难点需要多长时间、硬件/软件需求需要多少资金的投入。产品经理需要在会议中记录这些问题，并将总结成文档，会后一一落实，并总结出需求成本。之后在启动产品的研发。

那如何完整的评估产品中的这些难点呢？可以将产品分为不同的区块去分析，

按照不同的区块和产品流程的顺序去评估，会最大限度的评估出产品难点，避免研发中时在发现这些问题，导致返工或工期延误，成本不可把控，投入过大。