不管是做 2B 产品，还是 2C 产品，在确定产品解决方案之后，都没法保证这个解决方案是否已经被实现及市场验证，最好的方法是先进行市场调研或产品调研。

上一篇 ? 我们已经对「简报生成器」这个产品做了初步的需求分析，并且已经明确我们有比现有解决方案更好的方案。

一、To be or not to be ？

首先我们来简单回顾总结下我们提出的解决方案：按照用户预先设置的规则定时爬取各大新闻网站的新闻标题及摘要，然后将新闻标题归类整理在既定的早报格式中，然后将最终版的早报发送给用户。

产品解决方案已经确定了，那我们就可以开始做产品了么？

不管是做 2B ( to business，面向企业用户 ) 产品还是 2C ( to customer，面向个人、普通大众 ) 产品，在确定产品解决方案之后，都没法保证这个解决方案是否已经被实现及市场验证。当前最好的方式是进行市场调研或产品调研。如果当前市场上已经有这个产品了，那你就要决定是否还要继续进入这个市场。如果当前市场上没有这个产品，那你就要仔细分析为什么当前市场是没有这个产品（是因为没有需求？还是很难产生商业价值），然后决定是否还要继续进入这个市场？

我做了简单的市场调研，当前市场上跟早报相关的产品主要集中在两部分：

1. 专注早报格式的编辑器。如：图怪兽等各大编辑器，可编辑精美的图文早报，但内容要自己提供。

2. 专注内容的。如：fenng 大大的产品「Readhub」，可通过小程序订阅每天早报，但目前还不支持定制。

目前，还没有通过定制的方式满足我的需求的产品。所以，为了提高自己的效率，我决定为自己做这个产品。

二、确定产品形态：小程序？App？公众号？网页端？

不管选择哪种产品形态，首先要能满足需求。对于「简报生成器」来说，一个十分重要的需求是「能给不同的用户发送不同的消息（早报）」。这个需求对产品形态的选择起着十分重要的作用。

这个时候，我多么想我能懂技术啊。我想这一点或许是技术背景出身的产品经理的一大优势吧。那不懂技术怎么办？不要乱猜测，不要乱设计！最好找研发做个简单的技术调研，确认不同的产品形态是否都能满足「给不同的用户发送不同的消息」这个需求。如果都能满足的话，再考虑其它的点。如果只有一种形态能满足，那想再多也没啥用。

经过与研发的沟通与调研，以上产品形态均能能满足需求。

那接下来该怎么选呢？我们来简单看看每种形态的优缺点。

在调研小程序能否满足「给不同的用户发送不同的消息」这一需求时？我陷入了一种思维惯性，认为小程序是不满足需求的。因为小程序只能发送模版消息，也就是说每个人只能收到相同的消息，做不到不同的人收到不同的消息。但是转念一想，模版消息不就是通知用户早报已经生成了。

同时，我们只需要定制一个消息通知的模版消息，用户进入小程序之后就可以查看用户自己定制的内容了。给用户发送模版消息通知用户早报已经生成，就是为了告知用户该信息，以免用户遗忘。不知道你有没有因为思维惯性而怎么也找不到「答案」的时候呢？

综合考虑满足用户需求、开发成本、用户体验等多种因素，我决定通过「小程序」实现。

三、功能列表，确定产品的范围

当产品经理可以列出产品的功能列表，那么你已经定义出了这个产品的范围，也就是这个产品包含哪些功能特性。那「简报生成器」这个产品的范围层包括哪些功能列表呢？我们先看下「简报生成器」包括哪几部分：

灰色背景的部分（简报布局、简报生成）属于产品后端功能，用户在使用过程中对这部分内容基本无感知～

第一部分：简报布局

格式包括：纯文字格式和图文格式两种，需要预先配置在产品中以供用户自主选择。

优先级：低。内容本身比格式更重要。

优先级是用来描述功能（模块）对产品的重要性，为后续产品研发做参考。

第二部分：简报生成

这部分是整个产品的核心，目的是生成用户自己的简报。

优先级：非常高。内容的获得是重点，也是难点。

简报生成主要包括四大部分：

1. 内容获取：需要根据用户设置的信息源和类型、内容限制规则等爬取内容；
2. 内容缓存：为了提高效率和解决并发问题，需要有合适的缓存策略。因为用户对简报生成时间的要求相对比较集中，早上 8：00 – 9：00 会是一个高峰，如果没有合适的缓存策略，如果用户量较大，轻者会导致简报生成时间延迟，重者会导致产品宕机；
3. 内容整理：内容需要去重，以及需要按照类型整理内容；
4. 内容生成：按照固定的格式生成简报；
5. 内容发送：包括主动发送简报和被动发送简报两种。

“作为产品经理或者技术人员，很多人都想使用先进的技术、采用科学的流程做一个「高大上」的产品。比如「简报生成」这个模块，可以采用高大上的语义识别、机器算法精准的获取简报内容（标题和摘要），甚至还可以识别标题党，重新生成符合内容的标题……但是这个天马行空的过程忽略了最重要的一点，产品是用来干啥的？满足用户需求对不？那作为需求方的我，当前想要的产品就是采用技术所不屑的关键词匹配的方式提高我自己的工作效率，我不在乎你采用什么高大上的技术，只在乎能不能满足我的需求。所以，很多时候我们不要陷入自己的怪圈，要时刻记住「技术是为产品服务的，产品是为用户服务的」。后续产品满足基本的用户需求之后，可以继续迭代、优化产品，做得更完美。而当前最主要的事情就是赶紧上线使用。”

第三部分：简报设置

简报设置的目的是为了用户设置简报的格式以及简报内容的自定义。

优先级：高。核心模块。

具体包括以下内容：

• 简报名称：可支持用户自定义多个早报。
• 格式：可选择「第一部分：格式设置」内的格式。
• 信息源：设置自己的简报信息源，具体表现形式为添加网址。不过考虑到各种安全因素和减少恶意添加网址的可能性，第一版会提供固定的信息源供用户选择，后续可以通过用户反馈添加信息源。
• 类型：设置自己的简报类型，比如「科技」、「创投」板块，可通过关键词匹配实现，具体表现形式为添加类型名和添加对应的关键词。
• 内容：设置简报的内容范围和内容限制，比如取什么时间范围内的内容，简报内容的数量限制等等。第一版会以满足我自己当前的需求为主，通过简单的关键词匹配查找和爬取内容。后续为了让更多的用户使用，会增加多种规则设置完善简报内容。
• 自定义生成时间：设置早报的发送频率和发送时间。

第四部分：简报展示

本部分主要用于展示简报和查找历史简报。除此之外，以防简报生成出现故障或者用户需要预览自己的设置，需要提供「手动生成简报」的功能。

优先级：中。

第五部分：登录

本部分主要用于匹配用户信息和用户的简报设置。

优先级：低。

为什么需要登录？

因为需要将用户信息和用户设置的简报内容相匹配。另外，因为产品形态为小程序，所以可以直接授权微信的用户信息。

那可不可以不登录？

不是所有的产品都需要登录。如果用户不登录，用户只能查看通用的简报信息，「简报生成器」也只是向所有用户推送一样的简报内容。所以，如果只使用这些功能，那完全可以不登录。这也就是所谓的「访客模式」。

总结

1. 这一阶段，产品经理需要输出什么文档？

这一篇我们做了从产品解决方案到产品功能的工作，需要输出「规划的功能列表」，形式可以是思维导图，也可以是 Excel。

上一篇 ? 我们做了需求分析的工作，需要输出「需求可行性分析报告」，以确定这个产品能不能做。不过，大多时候没有强制要求，平时的工作也不会写类似的报告。

第一篇 ? 我们对用户做了访谈，需要输出「用户调研报告」，并同用户确认自己记录的内容，以免自己错误的解读或遗漏部分信息。在平常的工作中，2B 产品大多一封邮件就能解决问题，2C 产品需要做用户访谈的原始记录以留档。

2. 当你找到一个解决方案时，你需要做什么？

当前的产品解决方案，首先需要评估「使用现有技术是否可以实现？」。如果现有的技术不能实现，那你只是提出了一个理想的解决方案。在「简报生成器」这个产品中，我们第一步在选择产品形态时，就进行了技术调研，看现有的产品形态是否能满足当前的需求。

其次，需要评估技术难易程度如何？如果这个技术本身很难，鲜有人懂这门技术（语言），那后续的团队建设会遇到麻烦。

最后，还需要评估开发的时间成本如何？这里只需简单预估一下工作量，同时产品经理需要简单判断「有没有时间做这件事？」，以决定这件事要不要开始。

3. 2B 解决方案 和 2C 解决方案需要考虑哪些方面？

如果是 2C 产品解决方案，那你需要回答以下问题：

• 这个解决方案解决了什么问题？这个问题是真实存在的吗？这个问题还有没有其它的解决方案，各有什么利弊？
• 市场上有没有这个解决方案？没有的话，为什么没有？有的话，你和现有的解决方案有什么异同？

如果是 2B 产品解决方案，那你需要搞清楚以下几点：

• 这个解决方案的目的是什么？为了赚钱？为了支撑业务发展？
• 老板会不会同意你做这件事？为什么会？为什么不会？
• 老板是怎么考虑这个问题的？老板的关注点在哪里？

4. 产品的功能列表有什么用？

给自己和团队一个前行的方向，确定产品的边界，虽然后续很有可能会调整。

为技术选型、技术框架的搭建提供参考，就能避免后续提的需求被研发以「当前技术框架不支持，如果增加这个需求的话，我们需要重构 balabala…」为理由而拒绝。

5. 定了产品的功能列表之后，要做什么？

定义产品的 ROADMAP，也就是产品规划。产品规划就是说明我们怎么一步一步实现产品功能列表的计划。这个东西有什么用，敬请期待下一篇。

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

黄色为当前进度：

相关阅读

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

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

作者：左耳，微信公众号：产品碎月

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

题图来自Unsplash，基于CC0协议