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

32 评论 22153 浏览 126 收藏 16 分钟

不管是做 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协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 说实话,整体感觉有些怪,可能是比较零散的原因吧,作为产品工作方法论还需要进一步提取关键内容。

    来自四川 回复
  2. “用户登录”模块那里分为“第三方登录”和“微信登录”,但是小程序不是只能“微信登陆”嘛?

    来自广东 回复
    1. 这不是分开的,微信登录是说明这个早报生成器有那些第三方可以登录

      回复
  3. 确实很有用的文章,对思维逻辑很有作用

    回复
    1. 对思维逻辑?怎么说

      来自四川 回复
  4. 这还不是也可以理解为竞品分析跟思维导图的结合?

    回复
    1. 这是不是也可以 哈哈哈 打错了 求解

      回复
    2. 是的~ 🙂

      来自四川 回复
  5. 赞,期待你的下一篇文章 😉

    来自河北 回复
    1. 来自四川 回复
    2. 怎么关注公众号啊,是人人都是产品经理啊?

      来自北京 回复
    3. 微信搜:产品碎月

      来自四川 回复
  6. 我要赞一下! 😉

    来自上海 回复
    1. NSY?

      来自四川 回复
  7. 😉 继续等更新 lz太赞了

    来自四川 回复
    1. 来自四川 回复
  8. 小姐姐你好,我现在是iOS开发,也做过后台开发,现在在学习有关产品的知识,期待继续更新……也希望你可以给个学习建议和路线 🙂

    来自浙江 回复
    1. 我发了新文章了~~~

      http://www.woshipm.com/pmd/2265779.html

      来自四川 回复
    2. 或者你可以加我公众号「产品碎月」,后台和我直接沟通~

      来自四川 回复
    3. 话说你能简单介绍下自己么,不然我不知道从何说起

      来自四川 回复
    4. 这段时间太忙,都忘记了看回复。。。
      自我介绍一下:从事开发快4年了,主要做iOS开发,也懂服务器开发。现在不想再按照别人的想法来造轮子了。想转产品。对于产品这块没什么基础,不懂PS,不懂运营,更不懂产品,可能和环境有关,自己所接触到的产品经理都没什么货。。。就是画画原型图而已。稍微熟悉的行业就是金融和教育了。。。Axure自学了两个星期,大部分的交互都能画出来了,这些工具比起开发用的IDE还是很简单的。想尽快熟悉产品的工作内容以及需要掌握的知识和技能。能尽快面试一份产品的工作,降薪这个问题也做好了心理准备

      来自浙江 回复
    5. 不想再按照别人的想法来造轮子了。。。这一点,就算是产品经理有时候也要按照别人(比如:老板,市场等)的想法造轮子的。所以,其实没想象中那么光鲜。建议你多跟你现在的产品经理沟通沟通,看看他们是根据什么画原型的。另外,产品经理的工作远远不止「会用 Axure 画原型」那么简单。还是建议你先了解清楚。

      另外,Axure 用的再好,原型图画的再漂亮,不是成为产品经理的必要条件,只能算是充分条件。工具只是用来表达想法的,不能代表思考过程。

      来自四川 回复
  9. 学习了

    来自广东 回复
    1. 可以一起交流哈,看到后会回复的~

      来自四川 回复
  10. 非常喜欢您的文章。特地登录了来留言。PS,0409的文章和配图超级搭。我一开始只是点进来保存下图片的,随手往下拉才发现这篇好文章。

    来自浙江 回复
    1. 0409 的图是指哪个图啊?好奇脸.jpg

      来自四川 回复
    2. 就是一个人拿着气球。

      来自浙江 回复
    3. 那个是审核的人给的图,不是我的图 😀

      来自四川 回复
  11. 首先很感谢作者的分享,我还没来得及看其他文章,这个文章觉得写的挺好的,能对一些初学者提供些帮助,我这里面再针对用户需求方面补充几点希望能给后来看到的同行提供一些帮助。
    一、从用户需求到产品功能
    实际上产品的输出80%来自用户的需求,剩下的20%留给产品经理来进行发挥,那么在获取用户需求的时候需要确定几点的是:1、识别关键用户。我们这时可以有很多方法进行识别,如专家判断法等,只有识别了关键用户后才能更好地收集用户需求。2、需求分类。很多的时候用户提的需求都是一种设想、没有形成框架的,那就需要对需求进行甄别,哪些需求是真需求,哪些需求是伪需求,这个需要就具体的项目来看

    来自辽宁 回复
    1. 首先,「实际上产品的输出80%来自用户的需求,剩下的20%留给产品经理来进行发挥」,需求的来源不止这些喔,我这篇文章里有总结哈:http://www.woshipm.com/pmd/2182811.html(嘻嘻,打个广告)
      其次,「识别关键用户」确实很重要。不过,在我的工作中,我都是自己判断的,并没有使用专家判断法。。。尴尬
      最后,你说的「需求分类」感觉更像「需求识别」吧,很多用户提的需求都是在自己的认知范围内提出的自己认为比较好的解决方案,不一定是最优的,需要产品经理去判断有没有更好的解决方案。这一点,我之前的文章也有提~~你可以看看。。

      我能说我不是在打广告么 ➡

      来自四川 回复
    2. 有打广告的嫌疑哦,哈哈,针对产品的需求调研在整个产品阶段比重要占6成,这决定着后期的返工概率。很多时候做项目都会花很大的精力去做需求调研,只有调研清楚了才知道产品应该如何设计,需求识别是需求分类的前置条件,哈哈我昨天写的确实有些那个意思哦,还没写完忙着其他的事情就匆忙提交了,分类是将抽象的事情进行归类,然后进行具体化,这样对功能的设计会有很大的帮助,这里留一个question:如何产出一个高质量的PRD?欢迎小姐姐作答

      来自辽宁 回复
    3. 首先,需要明确 PRD 是给谁看的?为什么要写 PRD?
      最后,针对看 PRD 的人,只要他们能理解你要表达的意思,就是一份高质量的 PRD。

      至于格式、形式都不是很重要,达到沟通的目的最重要,不要为了写一份高质量的 PRD 而去写 PRD 就好。

      来自四川 回复