需求分析解剖产品想法

1、需求分析：解剖产品想法产品人总会产生各种各样的新想法，这其中极少数“应景且靠谱”的想法会成为产品、惠及网民，而更多产品想法只会成为谈资、或博文素材，比如下文中的这片想法。那么，产生不应景、不靠谱的想法是不是错误呢?我认为不是，这种“产生想法想法博弈想法毁灭”的过程，对于一个产品新人来说，至少算是一种对互联网市场的猜想、对用户需求的分析、对产品策划模型的创造。关键在于，自己是否可以通过简单的市场调研、理性的需求分析，对一个自己中意的想法做一次解剖，洞悉其价值。这种解剖分析的过程，就是锻炼和成长的过程。所以，我把以下这个想法拖上解剖台，按照“ 产生分解分析实现再回顾评估问题 ”的过程，简单评估一下

2、其应景与否、靠谱与否。需求产生： 我在 PC 上阅读的时候，总会在某篇文章中发现一些“或拍案叫绝、或醍醐灌顶、或发人深省”的片段内容。每当此时，总希望轻松存储这些片段，以便收藏并回顾，又不会干扰阅读进程。提升一点儿档次的说法，即所谓的“知识管理”行为之一。需求分解：1、在 PC 上阅读，所以场景有可能是浏览器、阅读器、WORD 等 ;2、阅读过程中存储片段;3、存储快速，以后可以阅读曾经存储的内容。需求分析：层一：有用实施文字存储行为，并方便以后的回顾阅读 ;存储行为在阅读过程中完成，要求快速且便捷。层二：易用网络存储： 最好玩点儿云存储的概念，我走到哪里都可以把片段往云彩里塞、或从云彩里看。

3、分类索引： 分类、 标签不能少， 甚至注释、 来源也可以有。 一是方便我对内容的管理 ; 二是说不定以后有大用处 如何快速：“浏览新浪博客时， 选中片段即可发布一条微博” 这种方式值得借鉴。在此过程中加入分类、标签、注释的交互过程，并淡化存储行为。造就一种“一片好知识，不知不觉已上云端”的完美感觉方便阅读：以某种方式让我舒服的阅读这些片段即可，比如网页方式。层三：爱用背景：满足了 “不打扰阅读行为的快速存储、有效索引、 便捷阅读” 这一基本需求之后，我所积累的知识就会不断的往云端里塞啊塞。如果这个产品被我的100 个其他同行使用， 我们 101 为同好者就会不知不觉建立起一朵肥硕的云彩，关于某

4、一类主题知识的云。基于以上两行之背景，则会出现如下之场景：第一：所有知识均为用户筛选，基本全属于优质内容。第二：分类索引，让同主题的内容可以有效聚合，并含有注释、来源。第三：有了优质内容、主题聚合， 分享欲望油然而生。 我当然希望浏览同行们认可并收藏的知识片段。需求实现：现有工具： onenote、EverNote 、 wiz 。试用了 WIZ ，索引及分类不清楚、存储有些迟钝。另外两个没用过， EVERNOET 本身 50M+ ，软件本身就够重的，有些麻烦。客户端嘛，最大的麻烦就是要安装和管理，一台PC 一种情况，带不走。阅读器， 比如谷歌。可以在有限内容源内收藏、分享内容，但其与需求本身还

5、有着本质差异： 阅读器， 并非知识管理工具，不能对片段精华的知识进行有效的存储、管理、索引。实现方式：客户端沦为现有工具之列，加入竞争。另外，客户端+网页的方式，也加大了用户的理解和管理成本。内容源：可以照顾各种内容来源，包括网页、WORD 等。浏览器插件比客户端轻、比“下面的方式”重。内容源：比客户端缩小一圈，可以照顾所有网页内容。某阅读器文摘功能最轻，内容源也最小， 限于阅读器订阅的内容。有可能背离最初需求， 第二种“ 有工具”。最 方式： 器插件+云端存 +网 展示。靠 ?回 需求即，回 最初的需求是否得到了很好的 足， 从虚 景中判断， 功能是否抓住了用 的痛点 (分析用 需求：在 景

6、中 找痛点 ): 景一：我安装了 器插件， 以后无 在网 中 到任何 于自己有价 的内容，均可“ 中内容 填 、分 、注 ，并自 来源完成云端存 ”。 景二： 我若需回 自己 累的网 文摘，开网 按照 分 及 ” 。便可以 “点 器上的插件按 打 景三： 承接 景二，我 可以在网 中“点 公共 、公共主 分 他人 生的 文摘内容关注某用 及其文摘知 or 点 文摘来源， 直接到来源网 览 or ”，社区形成。 ： 1 的需求有多 用 于“ 程中 精 、笔 内容，并作 知 管理、回 ”?2 由用 生的 “片段化的文摘、笔 内容” ，其可 性、 可分享性有多 ?第一个 ，决定了 个 品本身的“ 生意 ”。第二个 ， 决定了 个 品 “到底是做一个 粹的知 管理工具， 是借用 生 内容之 ，做一个知 分享社区。 ”解剖完 。 我 于 个想法的 估， 最后 以上两个 。当然，由于个人能力和 所限， 我 种自 自 式的解剖，会在 程中 生各种偏差或偏 。所以，最好的方式，是邀 其他同事、同行一起 解剖台， 自己的想法 足，以保 下刀精准、方向正确，从而 自己