了解用户基本需求
无论是产品经理,还是设计师,哪怕企业战略决策者也有焦虑。怕自己不了解年轻人,掌握不了未来。
所以需要“放之四海而皆准”、“第一性原理”的方法对“万变不离其宗”、“刻在基因里面的”的本性进行研究和探讨。
产品需求
用一句话简单粗暴的描述产品经理的工作:分析需求,设计功能,创造价值。
对需求的把握是产品经理最基础、最核心的能力。
用户需求被反馈者传递给产品经理(PM),PM通过去伪存真、去粗取精、概念化、图纸化,转化为技术可以实现的解决方案,该方案即是产品需求。
即满足用户需求,又满足产品目标的解决方案,才是产品需求。
需求的难题
挖掘与分析的难题:
- 人的贪嗔痴藏在自己的心中,谁会反馈给PM?
- 不同角色的反馈信息,如何辨别真伪和粗精呢?
- 有限的信息,又怎么能透视到用户的贪嗔痴呢?
- 人们之间的悲欢并不相通,怎么把握用户感受?
需求源(反馈渠道)
用户自己 与用户有关系的人 与用户没有直接关系的、自然环境内的人或事物
用户自己 | 主动表达 | 用户反馈、用户客服、用户调研 |
---|---|---|
与用户有关系的人 | 用户侧 | 与用户亲近的人代替用户反馈 |
企业侧 | 1、企业高层:决策层、业务层 2、产品分析:行为数据分析 3、团队同事:客服、运营、销售 4、合作伙伴:反馈调研 5、产品经理:体验观察 |
|
与用户没有直接关系的、自然环境内的人或事物 | 市场 | 1、政策调整 2、动态资讯 3、分析报告 |
竞品 | 竞争分析 |
用户反馈的局限
用户反馈其实是在表达情绪、讲问题、说方案,而不是在阐述真正的需求
- 情绪是什么?内心的造作。
- 问题是什么?现状与预期的差距。
- 方案是什么?人的本能是遇到问题会搜索认知范围内的事物组合输出成解决方案。
用户诉求的简化表达:
(1)知道问题,没方案,寻找方案 (2)知道问题,有方案,不知道方案对不对 (3)知道问题,有方案,不知道方案如何实施 (4)知道问题,有方案,但方案行不通,咋办 (5)知道问题,多种方案,不知道选择哪个最好 (6)知道现状不是想要的,说不清预期,没方案 (7)知道预期就是想要的,不清楚现状,没方案
面对反馈信息时要注意:
反馈角色:从我、他、自然的关系上换位思考。 情绪用词:统计占比,用于评估需求强烈程度。 问题描述:拆分为现状、预期,对比差距。 方案描述:仅做参考。
需要(Need)、想要(Want)和要求(Demand)
需求requirement
我们常说要分清需要(Need)、想要(Want)和要求(Demand)这三个需求类型。举个例子,有个人说他要一瓶可乐,这是“要求”,本质上是因为他渴了,要解决口渴的“需要”,而真正“想要”的是一杯可以解渴的饮料。需要是本质的痛点或需求,而“想要”是解决需求的手段,要求是用户自己认为能解决需求的方法。也就是说,当用户表达需求的时候,中间已经经过两层转化,辨认不出本质问题了。
Needs是指用户原始的动机成因;
Requirement是根据Needs产生的对产品的设计要求;
Demand是产品生产出来后市场上的需求量,常和供给量一起讨论。
分类方法很多
增量需求和存量需求
增量需求和存量需求
用户需求和商业需求
企业以“产品”为媒介,有选择性地满足用户需求,为用户创造价值,而后企业收获商业价值,这是一个先舍后得的价值交换过程,也是产品的最终目标。
产品经理对两者负责:其一是用户,用产品解决用户的问题或者痛点;其二是公司,或者老板,要盈利。
- 对用户——解决问题;
- 对公司——获得盈利。
因此,所有的需求基本可以分为两类:用户需求,商业需求。
比如微信,做即时通讯、朋友圈、摇一摇、附近的人等,都是解决用户需求。而在朋友圈插入广告、在钱包内置微粒贷、京东、滴滴等,是解决商业需求。
有些需求不太好分类,比如说,运营同学想做一个数据后台,方便及时查看用户数据。这个需求貌似即非用户需求,也非商业需求。其实,这属于用户需求,很多产品经理在工作中往往忽视一个重要原则:产品和用户是相互依存的!提到用户,要明确是什么产品的用户;提到产品,要明确产品的目标用户是谁。(先有产品还是先有用户?这是一个先有鸡还是先有蛋的问题。)
数据后台的用户,就是运营同学,所以产品经理做数据后台是在解决用户需求。
战略级产品需求、用户级产品需求、用户体验级产品需求
产品需求分为三种:战略级产品需求、用户级产品需求、用户体验级产品需求
1.战略级需求。这是产品需求中最核心的,它关系到整个产品模型,影响到产品的运营和商业模式,通过特定的目标人群的痛点制定的用户目标,然后将用户目标转化为产品目标,从而达到商业化的目的。
2.用户级需求。通过收集绝大部分用户的反馈意见和痛点,从而得到产品的需求/优化清单。
3.用户体验级需求。通过UED团队制定的体验优化方案,做用户体验方向的需求优化。
业务需求?用户需求?功能需求?
业务需求 | 用户需求 | 功能需求 | |
---|---|---|---|
定义 | 组织有价值的业务活动; | 围绕业务需求,从涉众角度思考如何实现业务需求; | 基于业务流程,系统应提供什么功能和性能; |
研究对象 | 组织 | 涉众 | 系统 |
业务需求:组织有价值的业务活动;
用户需求:围绕业务需求,从涉众角度思考如何实现业务需求;
功能需求:基于业务流程,系统应提供什么功能和性能;
如何挖掘需求?用户需求和商业需求
用户需求
做产品有一个原则:产品迭代,要么基于数据,要么基于用户需求。数据其实是用户需求的一个体现,归根结底,还是要看用户的需求。
挖掘用户需求,是一个技(ti)术(li)活,需要不断跟用户斗智斗勇。用户有个特点,就是自作聪明。当你询问用户有什么需求时,大部分用户会说我想要一个**功能,而这个功能是用户对自己的原始需求提供的自作聪明的解决方案。
比如,近期推出的新个税法有一条规定:从2019年1月1日起,所有的企业必须通知员工薪资发放详情。一个用户访谈如下:
问:新税法颁布后,有什么急需解决的问题吗? 答:我希望有一个工具,能快速的把excel按行生成截图。 问:为什么要批量截图呢? 答:这样我就能把截图发给员工了!一张一张的截太费时间! 问:所以你想快速高效的给员工发工资条? 答:没错!
从这个例子能看得出来,快速高效的发工资条是用户的真实需求,而批量截图工具是用户自作聪明提出的解决方案,明显这个方案是极其不靠谱的,因为它并没有很大程度上提高HR发工资条的效率。(用户需要的是上传excel然后一键发放工资条的工具)
挖掘用户需求时,不能只是听用户想要什么,更应该追根溯源,找出真正困扰用户的问题,然后去解决这个问题。
商业需求
除非是商业产品经理(这个title意味着直接对营收负责),大家一般对商业化需求比较排斥,因为商业化通常都会或多或少的影响用户体验。比如张小龙长期抵制在微信做商业化,后面实在扛不住了,才很克制的尝试朋友圈广告等。
商业需求通常来源于老板,理想的情况是:
老板:K啊,咱们产品用户量也蛮多的了,是不是该考虑盈利了?根据产品特点考虑下怎么商业化吧!
然后产品经理设计一个符合产品定位的变现思路,或者收费,或者通过流量变现。
但是,更多的情况会是这样:
老板:K啊,加个功能! 老K:蛤? 老板:就是用户可以! 老K:为什么突然加这么个功能? 老板:可以收费啊! 老K:so,是要割韭菜了么? 老板:真聪明!
其实商业需求比用户需求要简单明确的多,需要注意的是,如果遇到如上老板直接提需求的情况,一定要辨别他是在提用户需求还是商业需求,用户需求去跟用户求证,商业需求则要系统探讨商业化思路:是直接商业化还是间接的流量变现,两种思路完全不同。
马斯洛需求层次理论
Maslow’s hierarchy of needs
高级阶段 | 自我实现 self-actualization |
道德,创造力,自觉性,问题解决能力,公正度,接受现实能力 | Morality,creativity,spontaneity,problem solving,lack of prejudice,acceptance of facts |
---|---|---|---|
中级阶段 | 尊重需求 esteem |
自我尊重,信心,成就,对他人尊重,被他人尊重 | self-esteem,confidence ,achievement,respect of others, respect by others |
归属需求 love/belonging |
友情,爱情,性亲密 | friendship,family,sexual intimacy | |
初级阶段 | 安全需求 safety |
人身安全,健康保障,资源所有性,财产所有性,道德保障,工作职位保障,安放安全 | security of: body,employment,resources,morality,the family,health,property |
生理需求 physiological |
呼吸,水,食物,睡眠,生理平衡,分泌,性 | breathing,food,water,sex,sleep,homeostasis,excretion |
生理需求(physiological needs):呼吸、水、食物、睡眠、衣物 安全需求(safety needs):人身安全、健康保障、财产安全、工作 爱和归属感(love and belonging,亦称社交需求、社会需求):亲情、友情、爱情 尊重(esteem):自我尊重、被他人尊重、信心、成就 自我实现(self-actualization):价值观、创造力、责任感、示范带头作用、引领性
扩展以后的马斯洛需要层次,从5层变成8层:第6层求知的需要和第7层求美的需要是马斯洛的学生所加。 第三层效率的需要是笔者(闫荣 《产品心经:产品经理应该知道的60件事》)加的。
贪嗔痴
贪嗔痴
贪嗔痴、戒定慧、断舍离
(1)贪,对顺的境界起贪爱,非得到不可,否则,心不甘,情不愿。 (2)嗔,对逆的境界生嗔恨,没称心如意就发脾气,不理智,意气用事。 (3)痴,不明白事理,是非不明,善恶不分,颠倒妄取,起诸邪行。 戒,是指一种有道德的、有规范的、无害他人的生活行为标准,斩断因为沾染喜爱外物而生起的执着贪心; 定,是针对内心的修炼和自我耐性的培养;凡事先自省,向内求;避免外向的暴躁和苛求他人引发的嗔恨; 慧,是对于宇宙生命种种实相,有了透彻、圆融的了知,从而脱离愚痴;不再惘于事理,迷于因果;善解世间因缘的相续,明白生死流转的根本,心无挂碍,无有恐怖。 断=断绝不需要的东西 ,舍=舍弃多余的废物 ,离=脱离对物品的执着。
七宗罪
七宗罪seven deadly sins,天主教称七罪宗,或称七大罪或七原罪,属于天主教教义中对人类恶行的分类。归入这一类别的,能够直接形成其他不道德的行为或习惯。罪行按严重程度,由重到轻依次为傲慢、嫉妒、愤怒、懒惰、贪婪、暴食和淫欲。
6大类51种
6大类51种
梁宁老师的简洁模型
梁宁
五导家设计法
阿里巴巴提出的“五导家设计法”中“挖掘业务本质需求”的方法。提供了4个方向的基本问题,设计师可以通过这4个方向的问题,逐步了解需求的各个方面,并从中总结出需求的产品目标。这4个方向的问题是:
①需求来源和目标:为什么会产生这样的需求?需求是怎么发现的?要解决怎样的问题?目标是什么?
②需求方的解决方案,有没有待解决的问题还没有方案:业务方针对目标提出的(产品)解决方案是什么?具体是怎么想的?是否还有想要解决的问题没想好方案的?
③业务经验和数据:该业务经验性的特点有哪些?是否有数据或报告?产品/品类特色是什么?何种内容转化率高、点击率高?
④业务蓝图:业务后续规划的蓝图是怎样的?
以上4个方面的问题对于日常中的功能迭代,或是小型需求的分析,可以提供有力的帮助。对于大型需求,比如新增重要功能,或者新开发一个App,设计师还可以5个方面继续深入思考,获得更深层的见解。
1.定位的主要目标用户群体是谁?选取的是否合理?为他们带来的核心价值是什么?为公司带来的核心价值是什么?
2.整个业务流程是怎样的?盈利模式是什么?
3.市场/行业情况怎么样?未来的趋势如何?
4.竞争对手是谁?我们跟竞争对手相比的核心竞争力在哪里?
5.核心策略方向是否有效?发力重点是否合理?
设计师发现需要优化的功能,可以从以下三个方面着手:研究产品数据、进行用户调研/查看用户的反馈、进行可用性测试。
怎么排需求优先级?
重要需求决定明天有多美好;紧急需求决定能否见到明天日出;
在评定需求优先级时,通常要考虑紧急程度、重要程度、实现成本、产品所处生命周期等。有很多理论可以参考:Kano模型确定用户需求;预估需求实现价值;判断需求本身重要性;考虑需求来源;区分需求背景(需求实现目的);四象限法;
最常用的如KANO模型法(基本型需求>期望型需求>兴奋型需求)、四象限法(重要且紧急>重要不紧急>紧急不重要>不重要也不紧急)等,但实际操作中这些理论其实没那么好用,比如,不重要也不紧急的需求根本没有意义;
关于需求优先级问题,可以类比弹球小游戏:
规则很简单,各种小方块会回合制上升,玩家用小球消灭方块,任何方块升到顶端即宣告游戏终结。
类比产品经理解决需求:方块即是需求,其高度代表需求的紧急程度;其数量代表需求的重要程度。数字大的方块决定你能得多高的分,位置高的方块决定你能否继续玩下去。翻译过来就是:重要需求决定了明天有多美好,但紧急需求决定了你能否看到明天的日出。
游戏有几个小技巧:
- 尽量用一个球命中多个小方块;
- 上面的方块优先消灭,更要重视下方数字很大的方块;
- 礼物包无需消灭;
这也正对应了排定需求优先级时的一些原则:
- 尽量用一个功能解决多个需求;
- 不要迷失在紧急需求中,要时刻关注那些重要需求;
- 有些用户需求可以忽视;
总的来说,对产品新人,推荐尝试四象限法(重要且紧急>重要不紧急>紧急不重要>不重要也不紧急),经验丰富的产品老鸟,看到一张需求列表,结合产品的现状,自然而然就能排出优先级。
MoSCoW法则
莫斯科法则,就是Must or Should, Could or Would not。在排用户故事优先级的时候,把用户故事按以下4种类别排优先级。
Must:这个迭代一定要做的。比如前面提到的“必需”的功能。
Should:应该做,但若没时间就算了。比如前面提到的“不太需要的”功能。
Could:不太需要的,但有了更好。比如前面提到的“几乎早期版本中不要”的功能。
Would Not:明确说明这个功能不需要做,切勿把功能放到Must,Should or Could里。
四象限法
四象限法则,如重要-紧急、用户量-需求频率、效果-成本等。
KANO模型法
KANO模型法
具备↓不具备→ | 很喜欢 | 无所谓 | 很不喜欢 |
---|---|---|---|
很喜欢 | 可疑 | 兴奋性需求 (第三) |
期望型需求 (第二) |
无所谓 | 反向型需求 | 无差异需求 | 基本型需求 (优先干这个) |
很不喜欢 | 反向型需求 | 反向型需求 | 可疑 |
需求减法
重要用户优先原则
《需求评估矩阵表》
《需求评估矩阵表》
| 编号 | 需求
说明
| 类型/
模块/
来源/
| 用户需求满足程度
| | | | 产品目标符合程度
用户范围 |
| 发生频次 | 体验
差异
| 替换成本
| 研发
成本 | 品牌
提升 | 盈利
(广义) |
| 1
| xx
| yy
| 80
| 50
| 40
| 10
| 40
| 80
| 80 |
用户动机(集创堂)
来源:集创堂 2020-12
用户购物动机包含有【低价策略】(更加便宜)、【提高效率】、【更好体验】、【明确收益】、【控制风险】、【情绪附加】。
【更加便宜】主打的是低价策略,当人们需求更便宜的商品,而市场上却缺乏相应商品的时候(也就是卡牌里所说的“市场价位的空位感”),企业就可以制造出价格更低的商品提供给需求低价商品的用户,比如早期智能手机里面的小米手机,或者前几年异军突起的拼多多,都属于利用低价策略赢得市场的产品。
注意低价策略不能盲目使用,必须是市场上出现了“需求低价商品的用户群”,企业生产价商品才会有意义。【提高效率】指的是给用户提供更加高效的办法解决他的问题,当用户对当前常用产品的效率表示不满,急需新产品取代旧产品的服务时,我们就可以针对这部分用户提供更高效的产品,让他用起来更加简单、便捷,这点没什么好讲的,很容易理解。
【更好体验】指的是通过对用户情绪的掌控,为用户提供更佳的使用过程,或者直接一步到位优化用户的使用结果,它是在市场存在体验空缺的时候才能生效的一种动机点,如果当前产品让用户很不满意,用户就会想要去追求更好的体验。
最常见的提高体验的方式是“定制化服务”,就是专门为用户提供定制方案,只是这种定制化服务有很多只是口号响亮,在切实体验上并没有进行服务升级,大家在分析产品的时候,要懂得分辨哪些是口号,哪些是真正的服务提升。
【明确收益】指的是让用户感知到产品提供给他的好处,最好能让他清晰知道使用产品能获得怎样的好结果,这里面可以利用的方法有很多,比如告知用户原本无法完成的目的现在可以完成了,再比如告知用户他可以借助产品成为更好的人,又或者让用户感知到自身某部分的缺失,希冀通过产品体验原本从来没体验过的感受。
无论这种收益是短期利益还是长期持续性的利益,都能够让用户感知到产品的价值,只要他被这种利益点打动,就有可能付费使用产品提供的商品或服务。
【控制风险】指的并不是产品设计里的内容风险,而是为用户提供更佳安全可靠的产品服务,当市场上同类产品出现了明显的安全空缺时,如果用户群体开始关注安全这项属性(无论是信息安全、人身安全、资金安全还是别的安全),企业就可以针对安全进行消费动机宣传。
最明显的例子是儿童奶粉,或者食材和饮用水等容易爆发安全问题的领域,人们对这方面的敏感性比较高,比较不能容忍“不够安全”的问题产品,那么安全就是一个可以抓住的点,而另外一些安全敏感性较低的领域(比如说被褥,没人会在销售被褥的时候主打安全,一般都是温柔舒适保暖),推行安全就很难起到应有的效果。
【情绪附加】指的是在企业推出的商品上面附加更多情绪价值,以此带动更多的情感溢价,通常奢侈品采用这种方法比较多,这里主要针对的是马斯洛需求层次偏向上层的群体,可以直接从精神层面打动用户,让原本正常成本的商品售价超出市场常规售价,从而带来更高的利润。
很多产品都希望自己能够附加更多情绪价值,但是这一点并不是所有产品都能用好,大多数产品在销售的时候并不能刺激用户支付高昂的溢价,深厚的品牌是需要经营的,因此场景化消费更适合普通产品,就是在用户最需要一款产品的时候卖给他,他就有可能付出更高的价格。
需求评审(网易)
网易杭研项目管理如何评审需求?
【PS:偏资源管理、成本控制】
以前 | 现在 |
---|---|
需求评审:各角色的负责人(包含策划,交互,视觉,开发,测试,运营等角色负责人)来参与,没问题的需求全部进入交互阶段进行交互设计。 | 参与人员:策划,交互,视觉,开发,测试,运营等角色负责人。 评审目标:评审需求的优先级和价值,初步判断可实现性。 评审形式:集中会议。需求评审完成后的一天内,开发对需求的大小进行初步评估。从估算和计划的角度来看,可以认为是在需求细节还没那么明确的情况下的评估,可能存在50%±的偏差,但是他能将多余50%之外的需求砍掉,不必再进入交互阶段。 调整思路:增加了开发的初步评估,将大大超出团队容量的需求提前砍掉,减少了交互的工作量,使得交互稿可以提前交付,同时也避免了不必要的交互浪费,因为当前版本未能开发的功能,在下一个版本可能优先级就又不一样了,或者早已不符合市场需求了。 |
交互评审:所有成员(含所有策划,交互,视觉,开发和QA)参加,所有交互稿均会交付给视觉同学进行设计。 | 参与人员:团队核心成员(交互评审),相关功能的各角色成员(交互说明)。 评审目标:评审交互的合理性,以及交互的可行性评估。 评审形式:分为交互评审和交互说明。 整体交互稿的交互评审,在交互评审后一天内,参与评审的核心开发针对交互做一个基本的评估。反馈:哪些需求肯定做不完,这些需求就不需要全部进入视觉设计了。 在交互和视觉稿基本确认之后,在迭代后期,再分批跟相关功能的开发和测试进行交互说明。此时,开发的基本分工已经确认,大家会更细致来听,并且能够提出比较细节的问题,当然此时交互稿需要修改的问题会比较少,基本不影响整体的安排。 调整思路: 1.与需求评审一样,交互评审之后,基本上就能确认工作量,但是只需要核心的开发在交互评审之后的一天内大致评估工作量,定义是否有一些需求已无需进入视觉阶段,减少了浪费。 2.缩小参与交互评审人员的范围,让在场的人能够充分参与;节约未来参加评审的同学的时间。 3.缩小参与交互评审人员的范围,可能牺牲了一部分其他人的意见,为了补充这部分人的意见,所以在新迭代即将开始的时候再组织一次交互说明,不仅引入了这部分人的意见,同时也可以将交互做更细致的沟通。 4.最后的交互说明,不需要所有人同时过来,而是分批进行说明,这样既能让具体的执行人员能够了解交互细节,又不会浪费大家时间。 |
视觉评审:基本无 | 参与人员:相应的策划,交互,视觉,以及视觉负责人。 评审目标:评审视觉稿是否满足需求,以及从策划和交互的角度提出建议。 评审形式:当面沟通。视觉设计师会将设计稿邮件发给相应的策划交互,抄送开发,并且邀请策划和交互当面沟通意见。 调整思路: 1.视觉稿没有评审,经常在后期交互走查时发现问题。但是视觉稿的评审又不适合做的太重,视觉设计是一种无法明确定义好坏的,不是越多人参与就越好,所以只定义策划和交互参与,开发只需看实现上是否有困难即可(一般比较少)。 2.形式必须定义清楚,否则就会容易执行不到位。 |
1.所有需求都会进入交互设计和视觉设计阶段,但是最终有可能因为开发评估之后做不完而被搁置,造成设计资源的浪费。 2.交互评审全员参与,由于人数众多,而且分工还未确认,开发不知道自己负责哪部分,参与度很低,一般就是交互在讲,开发就在下面听,也不一定能提出问题,到了后半程,有些同学就开始玩手机,效率很低。 3.视觉评审的缺失,视觉评审没有约定明确的评审流程,所以有一些视觉没有经过评审就进入了开发阶段,直至需求走查的时候才发现有问题。 |
交互评审的时候,需要“核心开发”的参与,他要对产品整体的业务逻辑都非常清晰,能够评估新需求的大致工作量。如果团队中的开发都是独立负责一块,项目之间都不了解的情况,那就比较难采用这种方式。 视觉评审比较依赖大家的主动性,否则就需要视觉负责人来监督,是否所有视觉稿都经过评审。 |
李叫兽十个需求模型
李叫兽十大需求
低价需求:如果市场上,存在某些消费者,很渴望完成某个任务,但因为花费巨大,他们不得不放弃或者买个不给力的替代品。
过程体验:如果市场上的一些消费者,在做某件事时,不得不忍受很糟糕的体验,这时,他们就想要就行提升。
新颖性:如果市场上的一些消费者对过去某个一成不变的解决方案感到不满,就渴望尝试更好的新东西。
便捷性:如果市场上有这样的消费者,他们渴望亲自完成某一目标,但完成这个目标非常麻烦,常常需要付出巨大的时间、精力,这时就渴望有省麻烦、更便捷的解决方案。
可达性:如果你的目标消费者过去一直渴望达成某个目标、成为某种人,而始终没有途径做到,他们就希望存在一种实现目标的手段。
定制化:如果你的目标人群各自需求有所差异时,他们会希望你的产品能够有专属于他们的功能或体验。
性能:如果消费者一直想要完成某个任务,而现有产品的性能无法帮助他们完成任务时,就会想要性能更加先进的新产品。
高端:如果消费者很喜欢某类产品,但是这类产品却比消费者的其他选择更低端,阻碍了消费者购买,他们就希望有人能打破低端的常规。让这个产品变得更高端。
降低风险:如果消费者在购物前后,会担忧这次购物有某种风险,他就想要转而购买没有这种风险的竞品一-他们想要获得100%的保证。
理想自我:有很多消费者,一直没有意识到做某件事的重要性,而你提了他们,告诉他们这件事很重要(相当于给他们塑造了某种理想中的自我),他们就更加容易会做这件事,从而消费你的产品。
用户需求上线的三类问题
用户需求上线的三类问题
- 用起来的需求,用户不愿付费
- 付过费的需求,用户不愿续费
- 上线后的需求,用户没用起来