黄豆怎么成为豆腐-煜说产品05
在前面文章中，我们聊了产品概念怎么来，怎么采集需求，还有怎么分析需求。有了这些需求之后，怎么变成产品上的功能，如何迈出产品的第一步，这是同学们更关心的。
随着社会的发展进步，大多数基础的产品元素，或者说解决方案的组件，都是成熟的。在明白了用户的需求之后，是否能快速的组合出最合适，有亮点有创新的解决方案，是产品经理能力的体现。这样的能力，是需要长时间积累，用心的观察思考形成的。当然需求的转换，功能的细化，有一些行业通行的原则。
可见原则：保证页面的内容可见、状态可见、变化可见。我们要以小白用户的心态去思考每个页面需要展示的内容，用户不了解产品。
场景贴切原则：需要考虑用户在什么场景下使用，解决方案需要考虑符合用户在该场景下的使用习惯，在移动互联网时代，产品被使用的的场景越来越多样，地铁上、汽车上、躺床上、蹲厕所，等等。
可控原则：让用户对当前的情况，能很好的掌控，能够顺利的进入和退出。如果出现不能退出，用户就会很懵，不要假定用户对手机系统都了解的很透彻。
一致性原则：用户需要在同一个产品中接受同一套规范和逻辑，同样的功能需要用一套解决方案。最好和主流产品的规范和逻辑一致，减少用户的学习的成本。
防错、防呆原则：要尽量提醒和设计不让用户犯错。使用的流程要顺畅，让小白用户不费劲地使用。
协助用户记忆原则：在需要记忆某些信息的时候，帮助用户记录，比如登陆密码，比如购买物品的清单等等。
简约易读原则：页面足够简单，内容可读性强。让用户快速发现想要的信息，不要让用户无从下手。
容错原则：在可能犯错的地方提醒用户，并提供用户挽回错误的方法，典型的就是删除确认，让用户有避免误操作的可能。
帮助和提示：在任何用户可能不明白的地方增加必要的用户提示、尤其是新的解决方案，或者和主流不一致的时候。
灵活高效原则：要让用户方便、高效地完成任务。比如使用过的搜索词、使用过的emoji排在前面等。
恢复现场的原则：这个原则在移动互联网的大背景下，更需要留意，因为产品使用很碎片化，退出和切换会很频繁的发生。在发生各种切换和退出的时候要能有回复现场的能力，不需要让用户从头再来。
这些原则也适合产品的交互体验，用户是通过与产品的交互去解决问题的，好的解决方案体现在好的产品体验。
在一堆用户的需求中，我们推导出很多产品的功能，由于时间、成本等一些约束条件，在一次任务周期中，需要决定做哪个功能，做多少。一个功能有很多属性，最重要是：价值（商业价值），成本（开发量）和功能分类。
某个功能的价值，和产品当前要实现的目标密切相关，考察每个功能点的价值，是否对实现产品目标有帮助，帮助越大，价值就越大。具体从三个方面判断：
1、广度：潜在用户数*单用户价值。广度是从潜在用户数角度去判断功能的价值，在单用户价值差不多的情况下，当然是潜在用户数多的功能，价值大，优先级高。如果功能实现的价值很高，即使功能覆盖的用户数不多，该功能的价值也很高。
2、频度：需求频次*单次价值。不同功能的需求频次是相差很大，比如：吃饭是每天都需要几次，频次就很高；旅游每年可能出去几次，频次就不高。一般频次高，单次的价值就低，除非个别情况。从频度的定义可以知道，需求频次高，单次价值大的功能价值就大。
3、强度：不可替代，紧急，持久。强度代表了真实刚需。一个需求是不是刚性，有个简单的判断，“当没有这个功能的时候，用户是不是在设法解决，甚至已经在用一种低效的方式在解决这个问题？”。可替代性，就是这个功能是不是很容易被其他功能替代掉，不可替代，需求强度就大；科学的时间管理尽量避免紧急的事情发生，但实际中，受客观情况所限，必须马上要调整或者实施的，该需求的强度就高，价值就大；一个功能做完以后，用户的有效使用周期的长短也可以看作需求强度的大小标准。
在产品的不同阶段，产品看重的也不同。在早期产品概念验证的阶段，通过测试用户的留存高低，是否会反复使用等情况，判读是否找到了用户真正的刚需。那么“强度”就是产品追求的重点。验证完毕，产品上线，产品进入用户大面积提升的阶段，这个时候就需要重视广度了，能提升广度的功能价值就更大了。到了产品进入瓶颈期，用户数的提升没有那么明显，那么就需要提高频度来提升产品的价值。
成本是功能中另外一个重要特性，判断一个功能的成本有很多方面的考量，比如人力，时间、金钱，风险等，在互联网、IT行业更多是看工程师的工作量来衡量成本的高低，这个时候懂技术的价值就体现出来了，如果没有技术背景，就需要与技术的同学一起去评估功能的成本了。
知道了产品功能的价值和成本以后，就比较清楚的了解功能的性价比。一般情况下性价比高功能，优先级高。但实际操作的时候还需要考虑功能的另外一个特性：功能分类
我们采用KANO模型对功能进行分类：
第一类：基础功能（必备型需求）：这类功能，如果不实现，用户会很不满意，实现了用户认为是理所应当。基础功能是必须实现的功能点，无法带来满意，只能消除不满。
第二类：亮点功能（魅力型需求）：这类功能，如果不做，用户并不会不满意或者感觉有问题，一旦有了这个功能，用户就会大为惊喜，甚至“赞不绝口”，这类功能需要是我们探寻到需求背后人的本性才可以做出。亮点是忠诚度、口碑传播的基础。
第三类：期望功能（期望型需求）：这类功能都是用户期望的，对产品而言，“多多宜善”，选择性价比高的先做。如果只是简单地和用户交流来采集需求，最终实现的大多都是期望的功能。
这三类功能，随着时间的变化，功能的类型也是会变化的。亮点功能，随着行业的成熟也会变成期望功能，最后成为基础功能。随着市场竞争的日益充分，产品只有不断的创新，对市场进行有效的细分，快速找到产品的亮点。
第四类：无差别功能（无差异需求）：这类功能做不做用户都没有感觉，通过一些低成本的验证去决定要不要做这个功能。对任何要做的功能都可以做低成本验证，尤其是产品迭代的时候。
第五类：反向功能（反向需求）：这类功能是做的越多用户越讨厌，这样的功能是不是不应该做？其实不是，这些功能的需求既然存在，说明还是有用户需要的，产品的用户是多样的，KANO模型是对某一项功能的分析，不同的用户可能对这些功能的需求是反向的。反向功能需要我们做好取舍，这时候就要参考不同用户的重要程度了。
通过上面的方法，我们弄清楚了每一项功能的价值、成本及分类。产品和社会一样在不断发展，不断变化，在互联网行业，快速、迭代、验证是通行的法则，所以我们还需要决定打包什么功能在产品中，不要一次吃成胖子。
在产品的概念验证阶段，因为需要不断根据用户反馈去验证和修正，这个阶段，适合MVP的原则。MVP（Minimum Viable Produce），最小可用产品，满足用户需求的最小功能的集合，特点是成本要低，但是能展示最终产品的特色 。原则是：基础功能必须做，可以实现个别低成本的亮点；
在产品上线以后迭代阶段，期望的功能，先做性价比高的；无差别的功能不做，低成本验证出来即可；反向功能，权衡利益再做。
在打包产品功能的时候，还要注意，功能的依赖关系，这个依赖关系不单指功能之间，比如电商平台，必须依赖支付功能的完善。还有资源的依赖等实际情况。
很多平台型的公司，面对的用户有不同的角色，比如出行平台的乘客和司机，他们的角色不同，满足他们需求的功能是集成到一个产品上还是分开的好？这个主要考虑这些不同角色背后的自然重合度高不高，典型的例子就是，滴滴打车的司机和乘客，很难是同一个人，他们的需求差别也很大，所以最好分开打包功能。还有很多平台型的公司都有商家产品和普通消费者的产品。
