当我们提到一些常见的功能时，可以一笔带过，简单的描述一下就可以了，比如：对于微信登录，手机号注册。
那如果我们提到的是一些比较复杂的，具备一定创造性功能的时候，又该如何呢？
比如：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，就能建立起这道桥梁。
于是，问题变小了。
现在的问题在于，如何让用户输入“幸运ID”。
这个问题是不是变得简单了？
我们只是需要寻找一个能够让用户输入“幸运ID”的动机就好啦。
比如：
- 输入幸运ID，看看哪些朋友也在用
- 输入幸运ID，领取红包
- 输入幸运ID，可以抽奖
结局
这并不是唯一的解决办法，实际上很多需求都可以用不同的实现方法来解决。案例中的问题，我也没有将其完全描述出来，相信还剩下许多细节问题，留给大家思考。
工作过程中，我们经常会遇到非常棒的想法，但却无法将他实现出来，研发会向我们反馈“技术无法实现”。
据我了解，很多时候的“技术无法实现”是指无法实现这个方案，往往，我们换一个方案就可以实现了。
这就需要我们具备一定的技术认知，能够考虑到技术如何实现，他的思路逻辑是怎么样的。
案例中有一个小的细节，我们通过微信的open ID 来知道访问者是谁，如果没有这个open ID,那么这套方案就是“无法实现”的。
来看这个小故事：我们把微信的场景改变成QQ场景。
PM：我想知道有多少人在QQ访问了我们的网页
研发：这做不到，我只能帮你查查被打开了多少次，我不知道是“谁”访问了网页，因为他没有登录。（没有记录“人”，就没办法知道“多少人”访问）
PM：哦 好吧。
PM：我们可以用QQ的第三方登录吗，这样用户在QQ访问时，QQ就会把用户的信息传给我们。
研发:这样就没问题了，但你需要提一个需求，以前的数据就没办法了，这个需求实现以后，就可以统计了。
PM：好吧我去提个需求。
新需求：用户在QQ访问网页时，需要使用QQ提供的一键登录。