上一篇 我们介绍了产品规划，这一篇我们介绍一下产品的第一个版本。
产品的第一个版本要怎么做呢？
我一直比较认可一个观点，产品经理更像是家庭主妇而不是五星级厨师。五星级厨师是根据完美搭配的食材做出美味可口的食物，而家庭主妇是根据冰箱里现有的食材做出美妙的食物。
因为产品资源和上线时间的限制，很多时候产品经理都是在倒推每个功能或每个版本的时间点。简单点说，上线时间是确定的，团队成员是固定的，唯一不确定的是产品的功能。那怎么安排第一个版本的功能呢？
MVP？MDP？
提到第一个版本，有两个词就不得不说下：MVP ？MDP ？
首先，我们先看下这两个词分别代表什么？
MVP：Minimum Viable Product，最小可行化产品。产品的第一个版本需要为产品的早期用户提供他们需要的功能或传达产品的价值。简单来讲，产品第一个版本需要为核心用户提供核心功能，除此之外，一切从简。因为只有这样，才能保证开发速度，能够快速试错、快速迭代。
MDP：most desirable product，最渴望的产品。产品的第一个版本需要为用户提供他们最想要的产品，不只是功能上，还需要关注 UI、产品质量等。
最后，究竟是 MVP 还是 MDP？根据产品所在市场的生命周期决定。
导入期：推荐 MVP。快速推出产品，快速占领用户和市场是第一要素。这个阶段相当于市场的红利期，谁能快速推出产品，谁就是吃螃蟹的人。或者说，在食物种类比较匮乏的时候，你提供一个干面包可能销量就会很好。
成熟期：推荐 MDP。市场的成熟使得用户的期望变高，再提供简陋的产品将不再能吸引用户。或者说，食物已经有很多，各种各样，此时你再提供一个干面包，用户极有可能不理不睬。
同时，在做 2B 产品时，如果你的功能不能做到尽善尽美，如果竞争对手能快速复制并快速开发上线，那么你的优势将不复存在。此时，MVP 也就不适用了。
「简报生成器」应该怎么做呢？
先给结论，「简报生成器」是按照 MVP 模式进行的。一来当前市场上没有类似的产品，也就是说市场处于导入期，这个阶段适合采用 MVP 的模式快速占领市场。二来作为用户的我没有在当前市场里找到类似的产品，很关注功能是否满足，不在乎形式、UI 等。所以，我们第一版就按照最低标准交付，能满足用户需求，不追求形式。最终经过商榷（只有一产品一前端的情况），我们决定采用 txt 格式交付最终生成的简报，先确保这个模式走得通、流程设计的没有问题。
上一篇中我们已经了解到「简报生成器」第一个版本包含内容获取、内容生成、内容发送三大功能点。
内容获取 V1.0
首先我们来看下「内容获取」。「内容获取」主要包括以下部分：
(1) 从哪里获取
由于第一个版本是为了跑通流程，所以我们先提供一个网址用于获取简报信息。在具体实现的时候，我们发现，每新增一个信息源（网址）就要增加一个爬虫程序获取信息。这也验证了我们在整理功能列表时提到的信息源只能勾选，不能支持用户自主添加。因为没有背后的爬虫程序的话，只添加网址是没有意义的。
第一版我们暂定的网址是：https://readhub.cn/topics
(2) 获取哪些内容
之前已经提过我们是按照关键词区分不同的类型的，因此根据经验，我们将类型和关键词做了初步的整理，得到如下所示的关联关系。
热门：BAT、百度、阿里巴巴、京东、小米、抖音、知乎、腾讯、qq、QQ、微信
产品：宣布、启动、发布、新增
创投：融资、领投、募资、路演、IPO、招股、上市
科技：研发、特斯拉、亚马逊、火星、月球、发射、机器人
其它：（不含以上关键词的均属于这部分）
(3) 获取哪个时间区间的内容
因为我当前做到是早报，因此需要的时间区间为「昨天」的信息。在后续的版本中，该项会成为一个选择项，用户可以自主选择时间段。
(4) 什么时候获取
「即拿即用」。第一个版本可以接受点击「生成」之类的按钮之后去抓取结果（或从数据库里取结果），后续需要做到定时抓取、定时储存到数据库。
(5) 怎么获取
当然是写程序去网站抓啦，然后将抓到的内容存入数据库中。
内容获取 V2.0
当研发拿着内容获取 V1.0 的规则去爬取内容的时候，我们惊喜的发现这不是我想要的产品。具体表现为：
每种类型的简报非常少，而且相互有重叠；
大部分简报都归属于「其它」类。
为什么会这样呢？我们分析了下原因：一来关键词会重叠，如果一个关键词既属于类型 A，又属于 类型 B，程序是不知道它究竟是属于哪个类型的，当然产品给的规则也并没有明确这一点。二来很难提供全量的关键词匹配所有的内容。根据简报标题的关键词去区分类型，除非能给予全量的关键词去对应类型，才能保证简报和类型的一一对应。这件事在当前这个阶段根本就不可能实现。
综上，我们在选择信息源时，我们不再选用综合类的信息源，转而选用垂直领域的信息源。举个例子，之前我们使用的是「readhub」这种综合类新闻网址，在第二版中我们改用了「NEXT」、「知晓程序」这种产品类和小程序类的网站作为信息源。
在确定信息源之后，我们就针对每个网站分别设置内容的抓取规则。比如从「NEXT」上爬取了每日的产品，从「知晓程序」上爬取每日最新的小程序列表。
内容获取 V2.0 和内容获取 V1.0 最大的区别就在于「从哪里获取」和「获取哪些内容」，其余都是一致的。
内容生成
内容生成要求按照固定的格式生成简报。因为是第一版，要求比较简单，文字版就可以。这里只要提供一个简单的格式。
内容发送
「内容发送」用于用户主动生成简报。严格地讲，前面两步已经包含这一个功能点了。但为什么专门把这个功能点列出来，就是为了记录这一功能点，以免后期有所遗漏。
最终的效果
经过五一的劳动，我们把第一版的产品做了出来，具体效果如下图所示。
简报设置
如图，可以选择简报的类型和简报的日期，点击「生成」即可查看【简报结果】。
简报结果
【简报结果】界面是将爬取的结果展示在这里，只处理了「类型」。
按理说，这个界面只要实现基本的功能就行，不用关注 UI。但是写代码的小哥哥觉得界面太丑了，自己看不下去，然后简单处理了下。这其实就是属于「程序员自嗨」。不过，在不影响最终时间的情况下，作为产品我也是可以接受这种现象的。一来简单的 UI 处理花费不了太多时间，二来也是程序小哥哥想把产品做得更好一些，打击别人积极性总是不好的，只要最终的结果没问题就行。
这算是直接上手开发吗？
直接让程序员开发产品这件事肯定是不靠谱的，根本没法避免后期需要填多少坑。虽然我们在做一个临时的小项目，但是还是会按照「正规流程」走的。
团队成员只有两个人，一个我，一个程序小哥哥。我们两个在做这个项目的时候和以往做产品有些许不同。
- 沟通上。为了提高效率，我们采用了面对面沟通的形式沟通产品的细节以及我想要的最终的呈现方式。在团队人员比较多的时候，虽然面对面沟通这种形式必不可少，不过还需要记录文档留底，一来方面大家后续回忆当时为什么这么做，二来如果需要明确责任（扯皮），留底的文档是一个很好的武器。虽然我们是两个人，不过沟通完「产品架构」之后，我们还是简单的做个图留底。
项目管理上。虽然团队成员只有两个人，不过我们还是使用了项目管理软件 Tower 记录。这点和平时工作比较相像。在我们这个项目中，我们将项目分解成具体的任务，并明确具体的责任人。同时，我编写了 JSON 格式的「简报设置」文件和「简报结果」文件作为简要的需求说明，并记录在了 Tower 的项目里。过程中，由于「内容获取」有过修改，我们也是在对应 Tower 的任务下做了简单的描述。
原型设计上。这个产品的原型设计我没有采用 Axure 之类的软件，而是直接用笔在纸上画。一来方便沟通，二来简单省事。不过，有个不好的点是，纸容易丢失，不利于保存。如果你选择用纸来画原型，这一点一定要注意。
UI 和测试。没有专门的 UI 和测试同学，都是我们两个人分担。所以，我很担心程序有没有 Bug，丑倒还好些。如果你在一个小的创业公司做产品经理，可能也会遇到同样的情况，这个时候你千万不要只把自己当成「产品经理」，你还会身兼数职。这个情况产品经理大多扮演的是「补位」的角色，也就是俗话说的「哪里缺人补哪里」。
上线。程序小哥哥还在买服务器，等他处理完，我再来补充吧。
总结
1 为什么要关注产品的第一个版本？
产品的第一个版本就像你给别人的第一印象，非常重要。在社会心理学中，有一个词叫「首因效应」，指的是第一印象主导主体印象的形成。也就是说，你对一个人的总体印象如何，往往取决于你对他的第一印象。这是非常常见的一种社会知觉偏差。一般而言，第一印象一旦建立起来，它对之后的信息理解和组织，起着强烈的定向作用。而对产品来说，产品的第一个版本决定了产品在用户心中留下的形象，也在很大程度上决定了产品的生死。
但有一个很矛盾的点在于，很多时候我们希望第一个版本上线之后，就立马能够得到用户的反馈，不管是积极的反馈还是消极的反馈，但是很多时候，用户的反应都会「慢半拍」。也就是说，你很着急得想要看到第一个版本上线后的效果，但往往收不到太多的反馈。可能过了一段时间，市场的反馈才会慢慢多起来。就像谈婧在《重新定义分享》里提到的「Uber 和佟大为一起做活动」的例子，刚开始以为这个事件会达到一个爆点，然而没成想市场反应平平。活动结束后的一段时间，这个事件才达到了高潮。
2 产品第一个版本指的是什么？
或许你会说，产品的第一个版本就是第一个开发周期结束后的产品。如果你这么理解，那就大错特错了。这里的第一个版本是指产品上线之后，用户真正使用的第一个版本。
在真实的开发过程中，产品团队已经开发了好几个迭代，只是这几个迭代的成果都没有面临市场和用户的检验。也就是说，在面向用户的第一个版本之前，可能已经有很多个版本。当然，也有一些产品在开发了几个迭代之后，可能由于公司政策调整，也有可能因为需求的急剧减少，这些产品永远无法面向市场和用户，也就是说，可能永远都不会有第一个版本。
3 想清楚第一个版本的目标是什么？
（1） 验证需求是否存在？
当你不确定需求是否存在时，首先你要做的是验证需求是否存在。第一个版本就必须要搞清楚这件事，以免浪费过多的时间。验证需求是否存在，需要验证：1）这个需求是真实存在的需求？还是伪需求？可以通过用户过去的行为来判断。比如，用户说，如果小区能有健身房就好了。但用户上次去健身房可能是几年前。那用户说的这个需求基本可以判定为不靠谱。2）这个需求的频次是怎样？一个月一次，还是每天一次。比如，吃饭就是一个高频需求。3）这个需求是刚需还是非刚需？比如，一天不吃饭就不行，那吃饭就是刚需。
（2）验证设计是否合理？
在你已经确认需求是存在的并且是合理的情况下，那就需要验证设计是不是合理。这里需要关注 1）流程设计；2）交互设计；3）视觉设计（颜色、图标、间距、字体等），优先级依次递减。
2B 产品大部分属于这种情况，在需求明确的情况下验证设计的合理性。2C 产品大多属于第一种情况。
#### 4 下一篇？
下一篇我们将重点关注「功能打包」和「产品设计」，主要涉及「需求池管理」、「每个版本的功能列表规划」等内容，敬请期待。
好的，今天这篇文章到这里就结束了，我们的《一个项目带你走进产品经理的世界》系列文章完成进度如下：
黄色为当前进度～