产品方法论:一个漂亮产品方案诞生的过程

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

这是我总结的一个方法论,一个惊艳或者普通的idea,是怎么变成一个可执行的产品方案呢?

chanpinfangan

当我们提到一些常见的功能时,可以一笔带过,简单的描述一下就可以了,比如:对于微信登录,手机号注册。

那如果我们提到的是一些比较复杂的,具备一定创造性功能的时候,又该如何呢?

比如:APP推荐分享功能,老用户A将APP下载分享页,分享到朋友圈,或微信好友,微博,新用户B,C,D通过分享下载APP装机并注册,老用户A获得积分或其他奖励。

类似问题,会成为产品经理的一道分水岭,于我们而言,不只是想一些好的东西,还要有办法将他实现,这需要我们对技术有一定的基础认知。

常规的技术实现逻辑

几乎所有的互联网产品均会包含这四个环节:数据库,后端,接口,前端。但在某些产品里,可能会增加环节,或者用另一个方法来代替上图的某个节点,也可以减少一些环节。

“数据库”的存在可以被“日志”来代替。

一款无需网络支撑的“计算器”则只需要前端的功能支撑。

对于产品经理而言,我们有义务将一个idea转化成可用代码实现的方案,实际上这个转化过程正是产品经理重要技能的一环。

不仅仅是想到需求,还要确保需求可被实现。

1

对于互联网产品而言,一个idea一般都会牵扯到这4个环节,我们以登录为例。

2

这是一个简易的泳道图,我们可以这样来解读这幅登录的泳道图:

  1. 用户在前端执行了登录的操作
  2. 前端通过接口,将用户输入的帐号和密码上传到后端
  3. 后端将这些信息与数据库的用户信息表进行匹配
  4. 后端将匹配结果通过接口返回给前端
  5. 前端根据后端返回的信息来确定下一步是成功还是失败。

扩展

我们所说的异常保护,就是在上述的过程中,每一个环节都有可能出现错误,我们无法将所有的错误都进行预设,通常会将异常做分类。

没有返回以及返回的信息,不是“对”,也不是“错”。

所以一个登录功能,除了我们所看得见的登录成功,登录失败,还会有请求失败,请求错误这两个“功能需求”。

对于登录这类比较常规并且固定的功能,产品不需要过细的思考,但在一些个性化比较强的需求处理时,我们就需要将他尽可能的贴近实现方案。

复杂需求

案例

APP推荐分享功能,老用户A将APP下载分享页,分享到朋友圈,或微信好友,微博,新用户B,C,D通过分享下载APP装机并注册,老用户A获得积分或其他奖励。

3

这个是基于分享的泳道图,他能满足我们分享的需求,但显然,这不能完成案例中的复杂逻辑。我们来看看另外一副泳道图。

4

这个图补充了B用户在微信打开被分享出来的链接所对应的操作,但是这任然是不够的。

我们再来看看案例:

老用户A将APP下载分享页,分享到朋友圈,或微信好友,微博,新用户B,C,D通过分享下载APP装机并注册,老用户A获得积分或其他奖励。

我们还有几个问题没解决:

  • 我们如何知道B用户打开的是A用户分享出来的网页呢?
  • 我们怎么知道访问的人,下载的人,注册的人是同一个人呢?(条件是B下载装机并注册,A才获得积分)

第一个问题很好解决,A用户分享出去时,将用户的profile信息一起传给后端就可以记录下,“谁分享的”。

5

同时,在B用户访问时,我们也去记录下访问人的信息,微信提供了这样的支撑能力,在用户访问一个H5链接时,我们可以获得访问用户的微信ipen ID,这样就能知道谁访问了。

61

走到这一步,我们已经能够将这个案例实现大部分了。

A用户将下载页分享到微信,B用户访问了A分享的下载页,并做了下载动作。

第二个问题怎么办呢?

我们怎么知道访问的人,下载的人,注册的人是同一个人呢?(条件是B下载装机并注册,A才获得积分)

文章里已经用了较多的泳道图了,后面就不再贴图啦,大家可以自己画一画

我们在微信环境所记录的访问ID ,是以微信提供的Open ID 作为唯一标识的,第二个问题实际上是我们没有办法将Open ID 与用户注册时生成的User ID进行关联。

我们无法知道一个新注册的用户,是从哪里下载的。

然后

我很喜欢一句电影台词:如果不是喜剧结尾,那是因为电影还未完结。

我们设计到这里,已经能够发现问题了,那就能够找到问题的解决方案。

解决问题,产品经理应该是专业级的。

解决方案(参考)

我们要做的是将注册ID与访问用户的openID进行关联,中间欠缺一个可链接的桥梁。

于是,我们可以建设另一个桥梁,来起到替代作用。

我们可以在下载页作一个活动,每次用户访问这个页面时显示一个处理后的参数,这个参数是根据计算得到的,就像微信的open ID 一样。

访问者ID加上分享者ID再加上一些其他的参数,生成一个新的参数,我们可以将其称为幸运ID。

B用户只要在注册过程中,甚至注册以后的正常使用过程中,输入这个幸运ID,就能建立起这道桥梁。

于是,问题变小了。

现在的问题在于,如何让用户输入“幸运ID”。

这个问题是不是变得简单了?

我们只是需要寻找一个能够让用户输入“幸运ID”的动机就好啦。

比如:

  • 输入幸运ID,看看哪些朋友也在用
  • 输入幸运ID,领取红包
  • 输入幸运ID,可以抽奖

结局

这并不是唯一的解决办法,实际上很多需求都可以用不同的实现方法来解决。案例中的问题,我也没有将其完全描述出来,相信还剩下许多细节问题,留给大家思考。

工作过程中,我们经常会遇到非常棒的想法,但却无法将他实现出来,研发会向我们反馈“技术无法实现”。

据我了解,很多时候的“技术无法实现”是指无法实现这个方案,往往,我们换一个方案就可以实现了。

这就需要我们具备一定的技术认知,能够考虑到技术如何实现,他的思路逻辑是怎么样的。

案例中有一个小的细节,我们通过微信的open ID 来知道访问者是谁,如果没有这个open ID,那么这套方案就是“无法实现”的。

来看这个小故事:我们把微信的场景改变成QQ场景。

PM:我想知道有多少人在QQ访问了我们的网页

研发:这做不到,我只能帮你查查被打开了多少次,我不知道是“谁”访问了网页,因为他没有登录。(没有记录“人”,就没办法知道“多少人”访问)

PM:哦 好吧。

PM:我们可以用QQ的第三方登录吗,这样用户在QQ访问时,QQ就会把用户的信息传给我们。

研发:这样就没问题了,但你需要提一个需求,以前的数据就没办法了,这个需求实现以后,就可以统计了。

PM:好吧我去提个需求。

新需求:用户在QQ访问网页时,需要使用QQ提供的一键登录。

#专栏作家#

枯叶,近6年经验的产品经理,微信公众号:枯叶咖啡馆,人人都是产品经理专栏作家。擅长社交,社区,细分群体挖掘。

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

您的赞赏,是对我创作的最大鼓励。
5人打赏

评论( 17

登录后参与评论
  1. 不错学习了

    回复
  2. 写得好棒!最近在做面对面分享相关产品需求,有启发

    回复
    1. 回复

      很高兴能对你有所帮助~

  3. 非常喜欢您的文章 希望能有进一步接触 还望能传道授业解惑也!

    回复
    1. 回复

      关注我的微信公众号:枯叶咖啡馆,回复1就能找到我的微信号哦

  4. 很简单能看懂的一个过程图。。赞

    回复
    1. 回复

      做产品有一个原则,就是方便别人

  5. 你好,可以加下你的微信。

    回复
    1. 回复

      关注我的微信公众号:枯叶咖啡馆,回复1就能找到我的微信号哦

  6. 非常受用!!!招助理么?

    回复
    1. 回复

      可以一起讨论

  7. 一目了然啊 受教了

    回复
    1. 回复

      :|

    2. 回复

      多谢

  8. 语言简洁,容易读懂,受教了

    回复
  9. 启发好大

    回复
  10. 这篇通俗易懂

    回复
加载中