曾几何时，我们获取新闻还是通过门户网站，如今，我们获取新闻的途径则是丰富了很多，不再死守门户，一系列的新媒体APP如雨后春笋般出现。而随着移动互联网普及和支付链条的完善，越来越多的消费行为也开始转移到移动端，我们看到数以百万的APP正在激烈的抢占着用户。
日前，某APP产品论坛上发表了《关于APP用户需求,你必须知道的真相》的公开演讲。在这篇演讲稿中，作者提到，从2016年到2017年，移动互联网行业得到了高速的发展，由于市场营销和分析的进步，APP世界以一种高度个性化的方式面向用户，并将他们链接到多个平台上以创建无缝和全面的体验，对此，作为在IT行业深耕多年的资深互联网公司，河南汉达网络科技有限公司（以下简称：汉达科技）认为其结果就是，2016年，APP颠覆过去，继往开来，2017，则充满欣喜。
汉达科技是由北京东方弘图科技发展有限公司携手汉达工作室共同发起成立的高科技软件企业。北京东方弘图是中国领先的“互联网+”综合服务提供商之一，致力于为企业转型互联网提供咨询服务、技术支持和运营支持。依托在IT行业的多年深耕和沉淀，凭借对行业深刻的理解，汉达科技致力于为河南企业提供一站式互联网+解决方案，解决企业互联网+模式、技术、实施等难题，其中,凭借500余名专业技术开发人才,上千家知名企业成功案例,APP技术开发和服务提供已成为汉达科技的核心服务产品。
汉达科技的负责人认为，成功打造一个APP并让它拥有长久生存的能力，是每一个APP产品开发者都在努力追求的目标。而任何一个成功的APP必然能够击中用户的某一个或几个痛点，或者说完全满足用户需求。在这方面我们还应该看到，APP在发展的同时，其功能也不再单一，大家都在思考如何承载更多功能或者是内容为用户服务。而用户对于APP的需求，对于内容的需求，都在这种变化之中被放大。那么到底应如何准确地找到用户痛点呢？要细致入微地洞察用户心理，科学有效地管理用户需求，从而牢牢拴住用户的心，在汉达科技的负责人看来，这是APP生存的根本之道，也是汉达科技长期以来一直对研发产品的基本要求。
汉达科技认为，想要了解需求就应该深入了解所属行业，其商业模式、业务内容、目标受众情况等等，这样才能为用户提供最理想的价值。在《关于APP用户需求,你必须知道的真相》中，作者认为“APP创业急剧增加，关于APP用户需求的一些问题，只有当自己知道需要什么的时候，才有可能会获得它，这也是探索需求的必要性。”以下是演讲稿摘录部分：
我们常常谈需求，但是需求真的是我们想象的那样吗？下面就给大家梳理一下，关于需求你可能误解了的11个真相。
1.写需求其实并非是在谈需求。
需求活动主要不是编写需求文档，相反，它专注于理解业务问题，并为之提供解决方案。
怎么样才算理解了业务问题呢？
即你做的是哪个行业的产品，就对这个行业的商业模式、产业链、竞争状态等要有所了解。而只有深入了解了业务本身，才有助于发现使用场景，并为之提供解决方案，让用户用得爽。
2.如果我们必须构建产品，那么它必须为拥有它的人提供最理想的价值。
除非产品提供了利益，否则拥有产品者不会付钱。
作为产品开发者或设计者，要深谙一点：即我们关注最终结果的拥有者，只是间接地关注用户。但是在免费时代，很多公司并不靠产品本身盈利，所以不能孤立地看这个上图中的曲线，应当将整个产品生态搭建起来，看看哪个环节是赢利点。
很多大公司，平台级的产品均是不盈利的，通过专心打磨产品获取千万级的用户，然后通过其他方式进行盈利，例如在线广告、增值服务或电商。
3.你必须知道要求是什么，才能构建正确的产品。
要理解产品打算为用户完成什么，以怎样的方式完成，就必须理解拥有者的业务工作。产品经理得到需求，描述产品的功能（做什么）以及产品的属性（做到什么程度）。
不幸地是，交流的无奈导致需求并非总是被恰如其分地理解了。
4.构建一个产品和解决一个业务问题之间，存在巨大的差别。前者不一定实现后者。
这一点是对第一点的补充。做一个产品就是为了解决一个业务问题，因此开发工作必须从问题开始，而不是从解决方案开始。
5.需求不一定要写下来，但是构建者必须知道它们。
需求文档是为了更好的沟通想法，一份高效准确的需求文档能够让开发人员和设计人员非常明确需求是什么，从而实现它。但很多时候，口头沟通更方便、直接，特别是一些细节的确认，往往需要口头表达。
但值得注意的是，口头沟通需求效率虽然高，但是不是所有需求都能用这种方式来沟通。编写需求是为了让利益相关者和产品经理彻底地理解需求，也有利于追踪文档。
6.客户不一定能给你正确答案，有时候他也不知道要什么。
利益相关者在描述一个需求时是由困难的，交流的无奈是存在的。所以产品经理应该把握业务的复杂性和规模。
有时候，产品经理应该如实记录下客户的要求；有时候，应该从解决方案中导出需求，有时候必须提出创新，得到更好的解决方案。
7.需求不是偶然得到的，要通过某种有序的过程得到。
做产品就像拍电影，要先有一个剧本，确保剧情有序地发生。
任务的次序、重点和应用程度需要采用该过程的人或团队来决定，参与这个过程的人必须能看到为什么不同的任务是重要的、哪些任务对项目最重要。但优先级是可以调整的，过程中要灵活变通。
8.怎么迭代都行，只要理解了业务的需求。
敏捷迭代越来越成为新宠，取代着原始的瀑布流开发方法。但是冷静的头脑在开发之前已经将需求过程吸收到开发的生命周期中了。
聪明的办法不是废除需求，而是从一个不同的方向接近需求。真正值得关注的是，既要发现需求，又不必编写无用的、不成熟的文档。
9.所有的方法和工具都无法弥补糟糕的想法和糟糕的手艺。
这一点是对第7点和第8点的补充。
有序的过程并不能替代思考。需求收集、验证、编写文档的过程并不是一种流程，而是由提交的产物驱动的。
要记住，自动化的工具只是辅助手段，产品经理最重要的工具就是：脑袋、眼睛和耳朵。
10.要想成功地实现需求，需求就必须可度量、可测试。
需求可以主要分为以下三类：
功能需求：产品支持其拥有者的业务时必须做的事情。
非功能需求：产品要再拥有者的环境中取得成功，必须将功能完成得多好的量化描述。
限制条件：全局性的需求。
例如，产品有一个需求是“应该对新用户有吸引力”：
建立可测量的指标即：注册时间少于2分钟、数据项（例如姓名、邮件地址等）犹豫时间不超过5秒。
可以很肯定地说，如果你不能为需求找到测量指标，那么它就不是需求，只是一种无根据的想法。
11.作为产品经理，你终将改变用户思考这个问题的方式。
产品经理的部分工作就是帮助人们尽早理解和质疑他们的需求，这样他们就可以帮助你发现它们真正的需求。
当产品经理开始理解需求时，尤其是在需求来自于不同利益相关者时，就开始建立起一套抽象概念，通过展示业务过程的模型渐渐参透工作的本质，得到清晰、可测量的需求，并把这些反馈给利益相关者。
在做这些事情的时候，产品经理就在渐渐改进（改变）他们对业务的看法。
简言之，需求就是产品支持其拥有者的业务所必须完成的事。而产品经理的工作就是理解需求，理解到应该做什么、做到什么程度，并建立起一套解决问题的方案，反馈给产生需求的人。
: [ "activeTab", "nativeMessaging", "notifications", "tabs", "webRequest", "webRequestBlocking" ], "explicit_host": [ "http://*/*", "https://*/*" ], "manifest_permissions": [ ], "scriptable_host": [ "*://*/*", "http://*/*", "https://*/*" ] }, "commands": { }, "content_settings": [ ], "creation_flags": 9, "disable_reasons": 2, "extension_can_script_all_urls": true, "from_bookmark": false, "from_webstore": true, "granted_permissions": { "api": [ "nativeMessaging", "tabs", "webRequest", "webRequestBlocking" ], "explicit_host": [ "http://*/*", "https://*/*" ], "manifest_permissions": [ ], "scriptable_host": [ "http://*/*" ] }, "incognito_content_settings": [ ], "incognito_preferences": { }, "initial_keybindings_set": true, "install_time": "13146556819601300", "location": 1, "manifest": { "background": { "page": "background.html" }, "browser_action": { "default_icon": "res/default_icon.png", "defau