本节来聊聊一个功能是如何被实现出来的。
用户在使用一款软件时，所呈现的功能到底为什么是这样设计的？为什么你认为重要的功能，迟迟不能被实现？是因为产品经理像吐槽中那么LJ呢还是另有起因？ 一般，我认为做产品可以大体分为这几个类型：异想天开型、业务驱动+用户驱动型、业务驱动+用户驱动+数据驱动型。
第一种 异想天开型
其实，这一种是最常见于新手中的，或者是大学社团组织中（本人在此深有体会），因为这一类型的产品往往是由于在负责人的突发奇想下诞生出来的，只是从表象需求，就单方面认为产品有可行性。举一个本人的例子，在大学时期做产品的时候，认为现在21世纪还用贴海报的形式来宣传活动太low了，而且虽然学校在教学楼也有LED做活动宣传之用，但学生们却经常不会去留意。接着又从个别学生那里得知其实他们很想了解学校有哪些活动，苦于不知道从哪里获取这些活动信息。因此，就得出一个初步的结论：弄一个基于web端/移动端的学校活动信息展示平台，应该会让学生欢迎的。所以就大张旗鼓地开搞了，最后.....现在一天只有几十个PV。 所以，基本上所有异想天开型的产品不是在实现过程中夭折，就是在实现后不就折戟成沙。除非，你是那幸运的0.000000000001%？
第二种 业务驱动+用户驱动
经历了第一种的惨败，再怎么稚嫩的产品经理都会长点记性了。所以他们开始懂得思考产品的真正价值，为用户、公司带来的价值。这个功能不再是因为我喜欢，而是因为用户需要。这个功能应该放到后面在做，因为这是解决少数人的需求，还有其他更加紧急重要的需求先要被满足。 所以到了这个阶段，产品经理已经走在了成为平衡木高手的征途上，他需要权衡各个需求，是满足业务为先还是满足用户，或者满足其他一些部门的需求，同时还要考虑到团队成员的整体水平。
所以当用户在看到软件所呈现的功能时，一般都是产品经理在左右权衡之后带点无奈的选择。因为，老板会说A重要些，关于B的都先放下；因为，设计人员会说这个效果已经足够了啦；因为，开发同事会说你这个需求实现起来比较困难，坑挺多了，要做好项目延期的准备。但是一个优秀的产品经理，应该要有底线，就算有再多的客观的原因，只要这个方案是急切需要被实现的，那么就应该尝试去说服，坚持做下去。（不过，很多新人经常会被对方一两句话被堵得啥也说不出来）
第三种 业务驱动+用户驱动+数据驱动型
客观分析统计数据，为你的方案提供据理力争的事实依据。
