产品经理demo演示（一个项目带你走进产品经理的世界）

上一篇文章《一个项目带你走进产品经理的世界（4）：产品规划》介绍了产品规划，这一篇我们介绍一下产品的第一个版本。

一、产品的第一个版本要怎么做呢？

我一直比较认可一个观点，产品经理更像是家庭主妇而不是五星级厨师。五星级厨师是根据完美搭配的食材做出美味可口的食物，而家庭主妇是根据冰箱里现有的食材做出美妙的食物。

因为产品资源和上线时间的限制，很多时候产品经理都是在倒推每个功能或每个版本的时间点。简单点说，上线时间是确定的，团队成员是固定的，唯一不确定的是产品的功能。那怎么安排第一个版本的功能呢？

1. MVP？MDP？

提到第一个版本，有两个词就不得不说下：MVP ？MDP ？

首先，我们先看下这两个词分别代表什么？

MVP：Minimum Viable Product，最小可行化产品。产品的第一个版本需要为产品的早期用户提供他们需要的功能或传达产品的价值。简单来讲，产品第一个版本需要为核心用户提供核心功能，除此之外，一切从简。因为只有这样，才能保证开发速度，能够快速试错、快速迭代。

MDP：Most Desirable Product，最渴望的产品。产品的第一个版本需要为用户提供他们最想要的产品，不只是功能上，还需要关注 UI、产品质量等。

最后，究竟是 MVP 还是 MDP？根据产品所在市场的生命周期决定。

导入期：推荐 MVP。快速推出产品，快速占领用户和市场是第一要素。这个阶段相当于市场的红利期，谁能快速推出产品，谁就是吃螃蟹的人。或者说在食物种类比较匮乏的时候，你提供一个干面包可能销量就会很好。

成熟期：推荐 MDP。市场的成熟使得用户的期望变高，再提供简陋的产品将不再能吸引用户。或者说，食物已经各种各样了，此时你再提供一个干面包，用户极有可能不理不睬。

二、「简报生成器」应该怎么做呢？

先给结论，「简报生成器」是按照 MVP 模式进行的。

原因有两点：一来当前市场上没有类似的产品，也就是说市场处于导入期，这个阶段适合采用 MVP 的模式快速占领市场。二来作为用户的我没有在当前市场里找到类似的产品，很关注功能是否满足，不在乎形式、UI 等。

所以，我们第一版就按照最低标准交付，能满足用户需求就行，不追求形式。最终经过商榷（只有一产品一开发的情况），我们决定低成本交付最终生成的简报，先确保这个模式走得通、流程设计的没有问题。

上一篇中我们已经了解到「简报生成器」第一个版本包含内容获取、内容生成、内容发送三大功能点。

1. 内容获取 V1.0

首先我们来看下「内容获取」。「内容获取」主要包括以下部分：

（1）从哪里获取

由于第一个版本是为了跑通流程，所以我们先提供一个网址用于获取简报信息。在具体实现的时候，我们发现，每新增一个信息源（网址）就要增加一个爬虫程序获取信息。这也验证了我们在整理功能列表时提到的信息源只能勾选，不能支持用户自主添加。因为没有背后的爬虫程序的话，只添加网址是没有意义的。

第一版我们暂定的网址是：https://readhub.cn/topics

（2）获取哪些内容

之前已经提过我们是按照关键词区分不同的类型的，因此根据经验，我们将类型和关键词做了初步的整理，得到如下所示的关联关系。

• 热门：BAT、百度、阿里巴巴、京东、小米、抖音、知乎、腾讯、qq、QQ、微信
• 产品：宣布、启动、发布、新增
• 创投：融资、领投、募资、路演、IPO、招股、上市
• 科技：研发、特斯拉、亚马逊、火星、月球、发射、机器人
• 其它：（不含以上关键词的均属于这部分）

（3）获取哪个时间区间的内容

因为我当前做到是早报，因此需要的时间区间为「昨天」的信息。在后续的版本中，该项会成为一个选择项，用户可以自主选择时间段。

（4）什么时候获取

「即拿即用」。第一个版本可以接受点击「生成」之类的按钮之后去抓取结果（或从数据库里取结果），后续需要做到定时抓取、定时储存到数据库。

（5）怎么获取

当然是写程序去网站抓啦，然后将抓到的内容存入数据库中。

2. 内容获取 V2.0

当研发拿着内容获取 V1.0「按关键词做筛选，并归类到具体的类型下」的规则去爬取内容的时候，我们惊喜地发现这不是我想要的产品。具体表现为：

• 每种类型的简报非常少，而且相互有重叠。比如拿关键词「小米」去匹配，「小米旗下某某公司融资或上市」类的新闻也被归为「热门」，但其实应该归为「创投」。
• 大部分简报都归属于「其它」类。大部分关键词都匹配不到简报内容，或简报内容找不到对应的关键词，才导致了这种结果。

为什么会这样呢？我们分析了下原因：

一来关键词会重叠，如果一个关键词既属于类型 A，又属于类型 B，程序是不知道它究竟是属于哪个类型的，当然产品给的规则也并没有明确这一点。

二来很难提供全量的关键词匹配所有的内容。根据简报标题的关键词去区分类型，除非能给予全量的关键词去对应类型，才能保证简报和类型的一一对应。这件事在当前这个阶段根本就不可能实现。

综上，我们在选择信息源时，我们不再选用综合类的信息源，转而选用垂直领域的信息源。

举个例子，之前我们使用的是「readhub」这种综合类新闻网址，在第二版中我们改用了「NEXT」、「知晓程序」这种产品类和小程序类的网站作为信息源。

在确定信息源之后，我们就针对每个网站分别设置内容的抓取规则。比如从「NEXT」上爬取了每日的产品，从「知晓程序」上爬取每日最新的小程序列表。

内容获取 V2.0 和内容获取 V1.0 最大的区别就在于「从哪里获取」和「获取哪些内容」，其余都是一致的。

3. 内容生成

内容生成要求按照固定的格式生成简报。因为是第一版，要求比较简单，用文字版就可以。这里只要提供一个简单的格式。

4. 内容发送

「内容发送」用于用户主动生成简报。严格地讲，前面两步已经包含这一个功能点了。但为什么专门把这个功能点列出来，一来为了记录这一功能点，以免后期有所遗漏；二来后续可以做到订阅，每天定时通过邮箱等形式给用户发布简报。

三、最终的效果

经过五一的劳动，我们把第一版的产品做了出来，具体效果如下图所示。

1. 简报设置

如图，可以选择简报的类型和简报的日期，点击「生成」即可查看【简报结果】。

2. 简报结果

【简报结果】界面是将爬取的结果展示在这里，只处理了「类型」。

按理说，这个界面只要实现基本的功能就行，不用关注 UI。但是开发同学觉得界面太丑了，自己看不下去，然后简单处理了下。这其实就是属于「程序员自嗨」。不过在不影响最终时间的情况下，作为产品我也是可以接受这种现象的。一来简单的 UI 处理花费不了太多时间，二来也是开发同学想把产品做得更好一些，打击别人积极性总是不好的，只要最终的结果没问题就行。

3. 这算是直接上手开发吗？

直接让程序员开发产品这件事肯定是不靠谱的，根本没法避免后期需要填多少坑。虽然我们在做一个临时的小项目，但是还是会按照「正规流程」走的。

团队成员只有两个人：一个我，一个开发同学。我们两个在做这个项目的时候和以往做产品有些许不同。

沟通上

为了提高效率，我们采用了面对面沟通的形式沟通产品的细节以及我想要的最终的呈现方式。在团队人员比较多的时候，虽然面对面沟通这种形式必不可少，不过还需要记录文档留底。一来方面大家后续回忆当时为什么这么做，二来如果需要明确责任（扯皮），留底的文档是一个很好的武器。虽然我们是两个人，不过沟通完「产品架构」之后，我们还是简单地做个图留底。

项目管理上

虽然团队成员只有两个人，不过我们还是使用了项目管理软件 Tower 记录。这点和平时工作比较相像。在我们这个项目中，我们将项目分解成具体的任务，并明确具体的责任人。同时，我规定了 Web 端的输入和输出格式，并记录在了 Tower 的对应的任务里。即使过程中有过修改，我们也是在对应任务下做了简单的描述。

原型设计上

这个产品的原型设计我没有采用 Axure 之类的软件，而是直接用笔在纸上画。一来方便沟通，二来简单省事。因为我们第一个版本没有采用小程序的形态来完成，而是用 Web 端实现，本身不是很复杂。用纸画原型有个不好的点是纸容易丢失，不利于保存。如果你选择用纸来画原型，这一点一定要注意。

很多产品新人觉得 Axure 的技能要很牛逼，才能当一个合格的产品经理。其实，所有的工具只是辅助你达到目标的手段，用什么工具真的不重要，能清楚表达意思才最重要。我还见过用 Excel 画原型的公司呢，依旧不影响人家「活」得很好。这里打个小广告，后续我会整理「Axure RP 9.0」的系列文章，感兴趣的同学可以关注我哈。

UI 和测试

没有专门的 UI 和测试同学，都是我们两个人分担。所以我很担心程序有没有 Bug，丑倒还好些。如果你在一个小的创业公司做产品经理，可能也会遇到同样的情况，这个时候你千万不要只把自己当成「产品经理」，你还会身兼数职。这个情况产品经理大多扮演的是「补位」的角色，也就是俗话说的「哪里缺人补哪里」。

上线

我们现在使用的版本是在本地运行的，局域网内也是可以访问的。遗憾的是当前版本还没有在公网上部署，部署之后我再来补充吧。如果你感兴趣的话，可以在 Github 上查看我们这个项目的相关资料。

链接：https://github.com/HuaxinLab/briefing-generator

四、总结

1. 为什么要关注产品的第一个版本？

产品的第一个版本就像你给别人的第一印象一样，非常重要。

在社会心理学中，有一个词叫「首因效应」，指的是第一印象主导主体印象的形成。也就是说，你对一个人的总体印象如何，往往取决于你对他的第一印象。这是非常常见的一种社会知觉偏差。

一般而言，第一印象一旦建立起来，它对之后的信息理解和组织起着强烈的定向作用。而对产品来说，产品的第一个版本决定了产品在用户心中留下的形象，也在很大程度上决定了产品的生死。

但有一个很矛盾的点在于，很多时候我们希望第一个版本上线之后，就立马能够得到用户的反馈，不管是积极的反馈还是消极的反馈；但是很多时候，用户的反应都会「慢半拍」。

也就是说，你很着急得想要看到第一个版本上线后的效果，但往往收不到太多的反馈。可能过了一段时间，市场的反馈才会慢慢多起来。就像谈婧在《重新定义分享》里提到的「Uber 和佟大为一起做活动」的例子，刚开始以为这个事件会达到一个爆点，然而没成想市场反应平平。活动结束后的一段时间，这个事件才达到了高潮。

2. 产品第一个版本指的是什么？

或许你会说，产品的第一个版本就是第一个开发周期结束后的产品。但我这里提到的第一个版本是指面向用户使用的第一个版本。

在真实的开发过程中，产品团队已经开发了好几个迭代，只是这几个迭代的成果都没有面临市场和用户的检验。也就是说，在面向用户的第一个版本之前，可能已经有很多个版本。当然也有一些产品在开发了几个迭代之后，可能由于公司政策调整，也有可能因为需求的急剧减少，这些产品永远无法面向市场和用户，也就是说可能永远都不会有第一个版本。

3. 想清楚第一个版本的目标是什么？

（1） 验证需求是否存在？

当你不确定需求是否存在时，首先你要做的是验证需求是否存在。第一个版本就必须要搞清楚这件事，以免浪费过多的时间。验证需求是否存在，需要验证：

1）这个需求是真实存在的需求？还是伪需求？可以通过用户过去的行为来判断。比如用户说，如果小区能有健身房就好了。但用户上次去健身房可能是几年前。那用户说的这个需求你就要抱着怀疑的态度合理分析。

2）这个需求的频次是怎样？一个月一次，还是每天一次。比如吃饭就是一个高频需求。

3）这个需求是刚需还是非刚需？比如一天不吃饭就不行，那吃饭就是刚需。

（2）验证设计是否合理？

在你已经确认需求是存在的并且是合理的情况下，那就需要验证设计是不是合理。这里需要关注：

1）流程设计；

2）交互设计；

3）视觉设计（颜色、图标、间距、字体等），优先级依次递减。

2B 产品大部分属于这种情况，在需求明确的情况下验证设计的合理性。2C 产品大多属于第一种情况。

4. 下一篇？

下一篇我们将重点关注「功能打包」和「产品设计」，主要涉及「需求池管理」、「每个版本的功能列表规划」等内容，敬请期待。

好的，今天这篇文章到这里就结束了，我们的《一个项目带你走进产品经理的世界》系列文章完成进度如下：

黄色为当前进度～

相关阅读

一个项目带你走进产品经理的世界（1）：从收到一个需求谈起

一个项目带你走进产品经理的世界（2）：需求分析

一个项目带你走进产品经理的世界（3）：从用户需求到产品功能

一个项目带你走进产品经理的世界（4）：产品规划

#专栏作家#

佐珥，产品碎月（ID：pm_lab），人人都是产品经理专栏作家，专注互联网产品，乐于通过幽默诙谐、图文并茂、结合实际的文字分享自己的产品经验，期望同大家一起快乐成长

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议

,