需求分析：解剖产品想法

　　产品人总会产生各种各样的新想法，这其中极少数“应景且靠谱”的想法会成为产品、惠及网民，而更多产品想法只会成为谈资、或博文素材，比如下文中的这片想法。那么，产生不应景、不靠谱的想法是不是错误呢？我认为不是，这种“产生想法想法博弈想法毁灭”的过程，对于一个产品新人来说，至少算是一种对互联网市场的猜想、对用户需求的分析、对产品策划模型的创造。关键在于，自己是否可以通过简单的市场调研、理性的需求分析，对一个自己中意的想法做一次解剖，洞悉其价值。这种解剖分析的过程，就是锻炼和成长的过程。
　　所以，我把以下这个想法拖上解剖台，按照“产生分解分析实现再回顾评估问题”的过程，简单评估一下其应景与否、靠谱与否。
　　需求产生：我在PC上阅读的时候，总会在某篇文章中发现一些“或拍案叫绝、或醍醐灌顶、或发人深省”的片段内容。每当此时，总希望轻松存储这些片段，以便收藏并回顾，又不会干扰阅读进程。提升一点儿档次的说法，即所谓的“知识管理”行为之一。
　　需求分解：1、在PC上阅读，所以场景有可能是浏览器、阅读器、WORD等；2、阅读过程中存储片段；3、存储快速，以后可以阅读曾经存储的内容。
　　需求分析：
　　层一：有用
　　实施文字存储行为，并方便以后的回顾阅读；存储行为在阅读过程中完成，要求快速且便捷。
　　层二：易用
　　网络存储：最好玩点儿云存储的概念，我走到哪里都可以把片段往云彩里塞、或从云彩里看。
　　分类索引：分类、标签不能少，甚至注释、来源也可以有。一是方便我对内容的管理；二是说不定以后有大用处
　　如何快速：“浏览新浪博客时，选中片段即可发布一条微博”这种方式值得借鉴。在此过程中加入分类、标签、注释的交互过程，并淡化存储行为。造就一种“一片好知识，不知不觉已上云端”的完美感觉
　　方便阅读：以某种方式让我舒服的阅读这些片段即可，比如网页方式。
　　层三：爱用
　　背景：满足了“不打扰阅读行为的快速存储、有效索引、便捷阅读”这一基本需求之后，我所积累的知识就会不断的往云端里塞啊塞。如果这个产品被我的100个其他同行使用，我们101为同好者就会不知不觉建立起一朵肥硕的云彩，关于某一类主题知识的云。
　　基于以上两行之背景，则会出现如下之场景：
　　第一：所有知识均为用户筛选，基本全属于优质内容。
　　第二：分类索引，让同主题的内容可以有效聚合，并含有注释、来源。
　　第三：有了优质内容、主题聚合，分享欲望油然而生。我当然希望浏览同行们认可并收藏的知识片段。
　　需求实现：
　　现有工具：
　　onenote、EverNote、wiz。试用了WIZ，索引及分类不清楚、存储有些迟钝。另外两个没用过，EVERNOET本身50M，软件本身就够重的，有些麻烦。客户端嘛，最大的麻烦就是要安装和管理，一台PC一种情况，带不走。
　　阅读器，比如谷歌。可以在有限内容源内收藏、分享内容，但其与需求本身还有着本质差异：阅读器，并非知识管理工具，不能对片段精华的知识进行有效的存储、管理、索引。
　　实现方式：
　　客户端沦为现有工具之列，加入竞争。另外，客户端网页的方式，也加大了用户的理解和管理成本。内容源：可以照顾各种内容来源，包括网页、WORD等。
　　浏览器插件比客户端轻、比“下面的方式”重。内容源：比客户端缩小一圈，可以照顾所有网页内容。
　　某阅读器文摘功能最轻，内容源也最小，限于阅读器订阅的内容。有可能背离最初需求，沦为第二种“现有工具”。
　　最终方式：浏览器插件云端存储网页展示。
　　靠谱吗？回顾需求
　　即，回顾最初的需求是否得到了很好的满足，应该从虚拟场景中判断，功能是否抓住了用户的痛点（分析用户需求：在场景中寻找痛点）：
　　场景一：我安装了浏览器插件，以后无论在网络中阅读到任何对于自己有价值的内容，均可“选中内容选填标签、分类、注释，并自动记录来源完成云端存储”。
　　场景二：我若需回顾自己积累的网络文摘，便可以“点击浏览器上的插件按钮打开网页按照预设分类及标签阅读浏览”。
　　场景三：承接场景二，我还可以在网页中“点击公共标签、公共主题分类浏览他人产生的优质文摘内容关注某用户及其文摘知识or点击文摘来源，直接到来源网页浏览or”，社区形成。