如果你对于用户、行业、大环境有足够了解的时候，你就可以分析现下的问题，预测未来的发展方向提早布局，甚至去引导行业的发展。事物的发展总是有规律的，有足够的能力，就可以看清这脉络，看到这之间清晰的流动。

这几年总是忙于手头的项目，从APP到wap再到小程序和公众号，不停在变。而这变化也是基于业务，基于需求。想来互联网的大行业也是如此，每一两年都有当下的热门，有些渐渐消逝有些逐渐成型，而各位产品怕是也在不停的接受着这种冲击和压力。

那如果这个行业一直在变化，新的事物一直在出现，有没有一条线，可以把这些串起来呢，让我们接触新的产品形式的时候可以快速拆解上手呢？

刚好有些时间，可以总结下自己做产品的一些逻辑方法，也就形成了这篇文章。

一、账号体系

你的大脑是不是已经开始浮现起来几个词呢：账号登录、手机号登录、邮箱登录、三方登录，甚至你还会想到说这两年很多产品登录跟注册已经不区分都通用验证码了？

那，为什么呢？为什么账号体系会这样呢？而不同的登录方式根源区别又在哪呢？

如果我们抛弃一些细节，从现状往前推演这个变化过程，会发现什么呢？

（下文是笔者的推演，并未与历史进行验证，只作方法演示）

最初的最初，怕是我们最开始想要把一堆数据归集到一个人身上的时候，便产生了账号这种东西。可能是基于现实中的钥匙和锁的模拟（笔者编的），有了替代锁的账号，和替代钥匙的密码，如果你比较细心，在部分登录注册UI设计中，还可以看到这种锁和钥匙的图标。当我们通过了账号密码的验证，便可以看到基于这个账号的一系列用户行为数据。

而后来，产品越来越多，每个人使用的产品也越来越多，就出现了账号记不住和密码记不住的情况，甚至是因为账号或昵称是不可重复的，就有了：李四、李四被注册这样的名称。

所以人们开始尝试借用一些用户本身就在用的东西来作为账号，这个时候就有了邮箱、手机。而邮箱和手机这种独立于产品本身业务的东西，就不再是你注册只填写一个没人用过的用户名就可以注册了，而是你需要证明，证明你就是这个邮箱或手机的使用者，也就有了邮箱邮件验证、手机验证码验证。

这里有一个点需要注意，账号体系还是你内部的，只是，邮箱/手机是外部的。所以，你的账号体系只支持一种注册还是多种，注册后可以通过什么验证可以登录，有了账号把绑定行为触发放在登录前还是登录后，都是你自家的规则。

但是邮箱/手机这种介质、以及他们支持的验证方式，则需要去遵循它们的基本逻辑了。但是在他们的逻辑内，你是想给邮箱发个验证码还是带参数的链接，你想给手机发几位的验证码，是短信验证码还是语音验证码都是你去抉择。

那如何又有了三方登录这种东西呢？

你有没有发现，这些三方产品，是你的高频使用产品呢？微信、微博、QQ？因为大家的高频场景分布在这些产品上，所以就有了：我可不可以用微信的登录验证我在其他产品的登录呢？如果我把我的微信号跟你的账号绑定在一起，是不是证明了我是这个微信号的使用者，就可以登录了这个账号呢？

这个就是目前的三方逻辑了。

而基于上文的解释，你自然明白，三方是别人的产品，你如果想跟对方的账号体系发生点什么，是需要对方提供给你方法的。

以微信为例：如果你想接入微信的账号登录体系，那你肯定需要微信给你一个代表这个微信账号是这个微信账号的标识，而作为第三方，微信是不可能把微信号或者原始ID之类的东西给你的，所以它就生成了一个加密字符串作为账号的唯一标识，这个就是我们常说的openID。

但是你想接人家的账号，肯定有别家也想接，人家怎么知道你是你呢？

这样吧，你在我这里申请个商家账号。可是，你除了web想接，APP也想接，而且你还在微信那里有公众号小程序，还想把不同的场景区分开，但是又不想一个用户多个标识。这样吧，你每个产品都创建一下，都有自己的APPID、APPsecret，都有自己的验证方式，但是因为公众号和小程序是已经在微信那里有一套体系了，所以就跟你自己的产品绑在一起吧。

这个就是开放平台体系的雏形了，和基于单个产品的唯一标识的openID，基于开放平台账号的唯一标识的unionID。（如果你还想了解的多一些，可以研究下微信公众平台（公众号、小程序）、微信开放平台（APP、web）的接口分布）

但是别人的方法只是方法，账号体系还是你自己的，你把这个验证放在哪个步骤，你怎么拆分自家账号的登录注册流程，你验证了这个人就是这个微信号的使用者后要不要让他直接生成账号，还是补充个手机号或昵称再说。

他没有补充手机号或昵称是仅仅拦截了登录行为，还是连账号都没有创建成功（没有入库，存在账号体系表里），他绑了一个微信号还能不能再绑一个，或者再绑一个微博，这些除了验证方法之外的所有，都是你的规则，你的体系。都需要基于你的需求和你的分析判断结果，去梳理整个流程、利用这些方法。方法之外，最重要的就是你的目的。

二、逻辑方法

所以，看到这里，笔者想要分享的逻辑方法也就出来了：

1. 明确你要做什么；
2. 明确所有相关角色及他们的规则；
3. 设计你的方案、推进下去并观察结果。

三、笔者经验

以下，就这个逻辑方法，分享一些笔者的经验吧。

1. 明确你要做什么

如果我们描述一下产品工作的整个流程，大概就是：

你在一个平台上做了一个游戏，用这个游戏吸引一部分人过来玩，同时这些人在你这里玩的时候能给你一些价值。但是这个平台在变化，这些人也在变化，提供游戏的人也很多，所以你不断的设计新的玩法，升级你的游戏并且提高这些人在你这边创造的价值。

但是，你的老板可能不懂怎么玩只想知道一些结果、或者跟你说用别人那套玩法行不行，你的直属领导可能觉得你设计的新玩法不一定能达到预期的结果，所以你通过你的各种分析表达给他们看是可行的。

当你终于通过了老板和直属领导的认可，把你的玩法细节完善好告诉团队怎么实现，把你的玩法推动到团队去实施的时候，你的团队可能告诉你说，你设计的这套东西逻辑有问题，或者是你的细节不是很清楚好多情况没有给出处理方法，或者是其他业务线的人找到你，说你的玩法要是升级了，他们很多东西会受到影响，所以你不断的解决这中间的问题。

当你终于解决各种问题带领团队把这套新玩法正常推到线上以后，通过各种方法去观察新的玩法是不是真的有实现你的设想，在最初的设计中可能有的实现了有的没有。所以你不断的锻炼自己的能力，最终对于玩法的有效性控制力越来越好、你跟领导的沟通也越来越顺畅、你对团队的推动力也越来越强。

这整个流程用一句话总结下来，就是：为了更好的满足用户需求和内部需求，设计迭代方案，正确的推进下去并不断分析迭代。而实际在初期的工作中，其实一件事的目的并没有那么宏观，而是细分的，比如提高活跃；也可能一件事情的目的需要你自己去寻找的，比如：做一个新增平台的项目规划。这种时候，对于相关角色及他们的规则的熟知，便能更好的帮你分析确定要做的事情。

2. 明确所有相关角色及他们的规则

如果我们上来就进行角色分组其实会比较乱，这个时候你可以按照自己工作的行为路径去先进行划分，然后明确每个行为步骤中的相关角色。

2.1 需求阶段相关角色

（1）产品依存的平台

对于平台的分析，可以至少从两个方面需要了解：

• 平台定位：web、PC客户端、APP、H5、小程序、公众号等，不同的平台类型，有自己的定位，比如APP可以作为终极服务提供端，H5/小程序可以作为推广传播使用。
• 技术了解：比如web、H5跟浏览器玩，PC客户端跟桌面系统玩，APP跟手机系统玩，小程序/公众号则是基于微信的体系。对于基础技术的了解，可以帮助我们在遇到问题的时候有处去寻，比如做APP的需要关注iOS、Android的规则和技术迭代，比如做小程序/公众号的需要关注微信的技术更新日志及运营策略调整。

（2）用户行为及大环境/业务相关方/竞品

产品除了定义准目标用户及需求外，还需要做的是如何设计引导去满足，而这个过程，其实就是观察用户行为流动及进行相关引导的过程。关于这部分相关文章已经足够多便不再赘述。但有一点，对于用户的观察，一定要放到政治经济社会技术大环境中。

而业务方，相对用户而言，是对于内部需求实现过程中需要进行配合的。而二者的关系及侧重，则需要产品综合业务类型、企业基因、产品基因、优先级等多方进行判断。

如果你是刚刚接手一端产品，看看竞品公司的设计并分析设计意图，可以帮你快速的了解产品及行业。但是你在产品设计中做的决策，一定是在内部体系支持下的，因为不论业务再相似，也一定是有差别的，没有思考直接借用大多会给自己挖坑。

（3）领导层及其他产品线

产品规划过程，及方案的评审，都可能涉及到与领导层的沟通。如果你不是战略制定者，如何正确的理解产品战略诉求，并把自己的方案规划及项目价值以最大限度表达给各负责人，也是考验产品经理能力之处。

如果说内部团队的沟通可以更好的把控项目，则对上的沟通可以配合领导对于产品线的管理。自己闷头做自己的需求而不在意团队/其他产品线/领导，很多情况下并不是什么好事。

2.2 实施阶段相关角色

实施阶段的角色参与一般是在原型确定，或者文档细节完成后进行的，一般需要把握设计稿的完成节点、提测节点和上线节点，如果这之间有一些角色之间的节点冲突，便需要进行协调。

（1）UI/交互

规划阶段的产品及用户定位等，可以帮助设计师把握视觉及交互层的基本方向。

产品提测到上线期间，如涉及产品界面样式修改，会有一部分时间用于调UI。

（2）开发/测试

产品在平台基本技术了解的情况下，加深对于前台、后台、接口等的理解，关注用户行为和数据流动，设计过程中关注平台差异和设计点差异，这样做出的方案能够减少开发阶段的不确定。如果经历的项目较多，或者对于团队足够熟悉，在迭代方案制定时基本就可以确定这版方案的大概开发和测试周期，及跟进时的风险点。

如果涉及到跨平台的产品，比如APP内接入H5，原生和H5页面进行互相跳转，则需要进行不同端开发间的配合。

而基于平台的不同，开发测试的迭代特点也不同，APP有版本的迭代发布审核且区分iOS、Android，H5可以随时发布，小程序需要在微信公众平台后台提交版本，这些特点在配合上是需要注意的。

（3）业务对接

如果你手里的项目是业务相关性很强的，则实施过程中如果有需求变动或者上线时间调整，都需要与业务方进行对接以方便对方有时间去做准备。

2.3 上线后的相关角色

（1）业务对接

主要是上线后业务、运营的对接，以及产品培训。

（2）数据监测

针对想要达成的目的，进行相关数据的分析，以判断迭代的效果。如果是业务类系统，则需要向内部业务人员收集反馈。根据这些分析结果，作为后续迭代参考。

3. 设计你的方案、推进下去并观察结果

其实在第二步我们分析相关角色的时候，基本已经把方案设计和项目推进大概说了。这个过程无非就是针对第二步各个角色和你的需求，不断的提高方案的成熟度和项目的可控性。而需求的识别与转化、实际项目中的判断力，还是需要实操去磨的。这里就直接分享一些项目过程中的经验吧。

（1）短期方案和长期方案

不管是在迭代方案的确定中还是项目跟进过程中，都可能会遇到一些状况需要处理。有些比较大不好直接改，有些比较小就可以直接调。这个过程中，一定要分清哪些是长期的处理方案哪些是短期处理方案。比如，新项目接近上线还有一些问题，这时候产品协调各个角色保证本次上线是短期方案，上线后针对团队问题进行分析调整是长期方案。

（2）触发几率和严重性

这个主要用于产品上线时比较难改又发现晚的问题，或者是一些线上bug发现后的处理依据。比如：在商品支付项目中，订单金额的计算或显示错误就是严重性很高的问题，一旦发现是要尽早改的。但是比如一些UI问题，不在核心页面展示且触发几率比较低，则可以考虑后续迭代时修改。

（3）尊重各个角色、但维护团队核心诉求

不管是不同业务线的产品，还是UI/交互/开发/测试，还是相关的业务、运营，每个角色在团队中都起着各自的作用。产品对于项目中各个角色的工作理解越深，对于项目的把控力就越强，项目推进及上线时的风险就越小。

但是合作过程中难免会涉及一些纷争，沟通协调和解决是没有问题的，但是一定要维护团队核心诉求：就是团队工作的高效和项目上线的质量。

以上就是这篇文章的主要内容了，照应文章开篇的问题，这个方法不妨一试。但是如果你问，读了这篇文章是不是就可以毫无风险的去做一个从未接触的产品了？

怕还是不能的，因为项目的规划和跟进经验还是有差别的，但至少，如果你在经手的每个项目中都这样去思考分析，经历的项目越来越多，当新的东西产生并交到你手上的时候，以往的思考就会作为你强大的后盾，帮助你对新产生的事物进行快速的拆解。

而如果你对于用户、行业、大环境有足够了解的时候，你就可以分析现下的问题，预测未来的发展方向提早布局，甚至去引导行业的发展。

事物的发展总是有规律的，有足够的能力，就可以看清这脉络、看到这之间清晰的流动吧。

作者：无良，公众号：无良在想

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

题图来自Unsplash，基于CC0协议