在进入到课程学习之后，我发现一个课程设计者的小心思，如果从专业名词的角度来说，本次课程是《如何做好产品的可行性分析》，但是在选课界面（用户还没有打开课程时所看到的界面），显示的名词是《如何分析判断一个产品方案是否靠谱？》，这两个名称其实表达的是一个意思，但是课程设计者把语言优化成为一个所有目标群体都可以看得懂的名称，这是用户思维的体现，在我未来的产品设计中也要时刻把握一个关键原则：用户思维看产品。
一、什么是产品的可行性分析？
拿一个案例来说：上门厨师 谁是服务者
第一步：还原用户需求
1-谁需要：更多是用来招待，对菜品的口味和卖相要求更高
2-用来干嘛：要求是服务的提供者在节假日的饭点，提供所必要的服务，用以招待
第二步：谁能提供服务
1-餐厅、食堂本身
2-餐厅、食堂本身的厨师
3-做饭的阿姨
4-有手艺的普通人
5-厨艺学校的学生
第三步：服务者的诉求
1-餐厅、食堂的诉求是挣钱，但是个性化的需求难满足，更倾向于外卖等高效率的服务
2-餐厅、食堂的厨师的诉求是多挣钱，但不能得罪现任雇主
第四步：明确三方角色矛盾
1-用户
2-服务者个体
3-服务者背后的雇主
第五步：谁来提供服务
1-服务者群体：餐厅厨师？ 不行（模式）；食堂厨师？ 可以备选（手艺）；做饭阿姨？ 可以；普通个体？ 可以；厨艺学生？ 可以
2-选择服务者：首先做饭阿姨；次选普通个体；再选食堂厨师
3-如何找到做饭阿姨：
家政公司、职业介绍所
4-有手艺的个人：
这些人的问题是什么？-做菜慢、手艺不稳定
解决方案是什么？-培训、观察考核
5-找到核心关键难题：
关键思考点：
还原用户需求→罗列可能完成服务的角色→明确角色的特点和诉求→推演完整的流程→形成服务的闭环
二、学习内容内化
那么接下来就以我自己工作中的一个实际的产品方案来思考，今天学习的课程如何去具体的落地应用。
我所负责的产品中属于是TO B的一款项目类产品，这种产品有一个特点，基层人员真的用起来之后会产生与公司其他系统进行集成的天然需求，因为这样客户可以将更多的管理需求通过工具类产品落实到基层，那么用户的需求就产生：客户想要我们的项目类产品与管理系统集成，实现数据的互通。、
在该需求下，有四个角色：项目类产品方（我）、客户公司、管理系统提供方、客户基层人员。
每一个角色在整个集成过程中的特点和诉求是不同的。比如项目类产品方，我们的需求是可以与客户的管理系统进行集成，给我们带来的好处是与客户的整体业务粘性增强，客户的替换成本变高，且为我们进行深一步的业务价值挖掘提供资源；但是集成的结果是不能够直接影响到产品的应用，因为我们是项目类产品，应用的次数越多，频率越高，我们的价值才越大。
对于客户而言，其考虑基层员工使用的权重更小一些，其真正关心的是公司的管理政策能否通过集成有效的落地，收集回来的业务数据是否是其真正需要的数据。
管理系统方的态度相对是比较消极的，因为与我们的集成并不会给其带来直接的好处，且还可能需要其配合做一部分工作，所以他们做集成的原始动力不足。
客户的集成管理人员，是整个环节中非常重要的一环，如果因为集成导致其操作繁琐或者带来更多的业务负担，那么其的使用意愿会持续降低，这是严重违背项目类产品的初衷，也是违背客户初衷的（因为没有应用就无从谈起政策落地）。
那么这个集成到底应该怎么去做才能实现业务的闭环呢？这里只说几个粗略的原则：首先是客户需要落地的管理数据，通过集成可以稳定不遗漏的传递到项目类产品；其次是基层客户在使用过程中能系统自动完成的不用客户手动操作；再次是如果管理类系统不配合做工作，我们提供所能提供的所有支持，同时与客户的关系做好，使其影响管理类系统。
最终的完整服务流程可能会是：按照客户的要求，管理类系统将需要的数据推送到项目类产品，然后基层人员在使用过程中，为减小业务负担尽量自动完成数据的采集和挂接工作，然后推送回管理类系统使用。
