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

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

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

比如：

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

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

常规的技术实现逻辑

几乎所有的互联网产品均会包含这四个环节，数据库，后端，接口，前端。

但在某些产品里，可能会增加环节，或者用另一个方法来代替上图的某个节点，也可以减少一些环节。

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

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

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

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

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

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

用户在前端执行了登录的操作

前端通过接口，将用户输入的帐号和密码上传到后端

后端将这些信息与数据库的用户信息表进行匹配

后端将匹配结果通过接口返回给前端

前端根据后端返回的信息来确定下一步是成功还是失败。

扩展

我们所说的异常保护，就是在上述的过程中，每一个环节都有可能出现错误，

我们无法将所有的错误都进行预设，通常会将异常做分类。

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

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

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

复杂需求

案例:

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

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

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

我们再来看看案例：

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

我们还有几个问题没解决

我们如何知道B用户打开的是A用户分享出来的网页呢？

我们怎么知道访问的人，下载的人，注册的人是同一个人呢？（条件是B下载装机并注册，A才获得积分）

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

同时，在B用户访问时，我们也去记录下访问人的信息.

微信提供了这样的支撑能力，在用户访问一个H5链接时，我们可以获得访问用户的微信ipen ID，这样就能知道谁访问了。

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

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

第二个问题怎么办呢？

我们怎么知道访问的人，下载的人，注册的人是同一个人呢？（条件是B下载装机并注册，A才获得积分）

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

我们在微信环境所记录的访问ID ，是以微信提供的Open ID 作为唯一标识的。

第二个问题实际上是我们没有办法将Open ID 与用户注册时生成的User ID进行关联。

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

然后

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

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

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

解决方案（参考）

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

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

可以在下载页做一个活动，

每次用户访问这个页面时显示一个处理后的参数，这个参数是根据计算得到的，就像微信的open ID 一样。

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

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

这样我们就可以完整的实现案例的场景了。

1.通过记录分享者的user ID， 我们可以知道某个H5是A分享出去的

2.通过记录访问者的open ID ,我们可以知道是B打开了A分享的网页

3.通过幸运ID，我们能知道B用户是通过A分享出来的网页下载并注册的。

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

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

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

比如，

输入幸运ID，看看哪些朋友也在用

输入幸运ID，领取红包

输入幸运ID，可以抽奖

结局

这并不是唯一的解决办法，实际上很多需求都可以用不同的实现方法来解决。

案例中的问题，我也没有将其完全描述出来，相信还剩下许多细节问题，留给大家思考。

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

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

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

案例中有一个小的细节，我们通过微信的open ID 来知道访问者是谁，

如果没有这个open ID,那么这套方案就是“无法实现”的

小故事

PM：

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

研发：

这做不到，我只能帮你查查被打开了多少次，我不知道是“谁”访问了网页，因为他没有登录。

（没有记录“人”，就没办法知道“多少人”访问）

PM：

哦 好吧。

PM：

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

研发:

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

PM：

好吧我去提个需求。

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

（解决了想知道多少人访问的“需要”）

我是小硅，文中的案例来源于一位朋友在QQ群的提问，我正在四处收集问题。

如果你在工作过程中遇到了各种各样的问题，来硅谷堂公众号告诉我们吧。