到底TMD第一用户是谁?

❝我发现，面对需求，不管是产品经理还是程序员，虽然嘴上成天挂着“User First”，身体却很诚实，不自觉的“Self First”或“Functionality First”。设计出来的产品或者架构，经常是自我陶醉或者功能堆砌，而不是关注真正用户的本质诉求。

从(软件)产品的生命周期中寻找"用户"

在NPDP的理论体系里，产品历经起步期Introduction、成长期Growth、成熟期Maturity、衰退期Decline。而市场投放过程中参与的用户一般划分为创新者Innovator、采纳者Adopter、主流用户Early Majority等等，精准识别用户对于前期市场的产品导入非常重要。

在IT从业的眼里，软件产品通常循环在需求、架构、设计、编码、测试、发布、运营这个闭环。最后这个“运营”是大多IT人以为的，唯一可能与市场有交集的环节。其实，从拿到一个软件产品的商业计划书或者业务需求开始，IT人已然在闭环中展开了与市场的博弈角逐，能(容易)实现么？要优化体验么？A/B Test么？MVP到底包含哪些？PMF应该是什么状态？... 用户，隐于市场中。

所以用户的定义到底是什么？

俞军老师从需求的角度定义用户是“某个场景下的需求集合”，有点过于抽象。而我更喜欢的对用户的定义是“乐于/勇于/包容地享受产品的体验并满足了自身需求的人”。通常我们只关注到了满足需求这后半截，却忽视了享受产品。有人要问了，差产品何谈享受？所以我加上了定语“乐于或勇于或包容”，初期产品再差，也有人愿意使用并给予极大的宽容，这才是这款产品需要用心服务和经营的“用户”。若产品多次迭代后还差，那一定活不过十五，也就别提什么用户了；若产品变优秀，以前天天骂产品的抵制者也会默默的变为忠实用户。

那么问题来了，一款 软件产品 的第一用户应该是谁呢？

我的答案是，“虚产品”的第一用户是“产品经理”，“实产品”的第一用户是“程序员”。

虚产品 - 产品经理

俗话说产品经理生孩子，运营经理养孩子。产品经理设计产品的过程，就是从用户的视角不断感受、理解和体验产品的过程。再白话点，产品经理是第一位靠“脑补和YY”体验产品的用户。故而，虚产品无他，唯仍未实现或发布的“PPT/Axure"耳。今天我却不想借喻父母来形容产品经理，修真小说里常用的这个词在我看似乎更加贴切：

夺舍

产品经理就应该是那个随时住进(夺取)用户身体里的鬼神，可以通过用户的五感来感知世界。

给运营人员设计运营平台的录入功能，你可以设计为单条提交，也可以优化为批量提交，更可以提供Excel导入。我经常听到的一句话是“需求方都是贪得无厌的”(倒也没啥错...)，但是如果你作为运营，面对着大量录入工作，使用着单条提交的功能，你也会骂娘的吧？只是没有体会运营苦。

在地推人员手持PAD的APP里设计的进件功能，只是因为风控部门的一个不可退让的策略，某个字段不允许人工修改，产品经理也深知这个字段填错需要修正的概率极大，但是拗不过风控，不得不妥协为不可修改的设计。投产后果不其然，这个字段大量的填写错误，客户就在地推面前，时间不等人，IT团队不得不疲于应付，费劲地在后台修改数据。产品如何站在地推的角度撕逼风控呢？我一直说很多问题不是不可调和的矛盾，也不是非A即B的二选一。这不就是一个配置开关或者白名单的事情么？凡事都有例外，让填错的用户成为一种例外即可。真心呼吁，请让例外成为一种产品设计。

产品经理，其实也不容易。上面的例子也侧面体现出，有些时候他们真不是没有用户视角，而是因为用户体验从来都不是无节制的自由享受，一定是在某些规则限制内展开。如何做好体验和限制之间的平衡，才能彰显出产品经理的真本事。

实产品 - 程序员

我一直这样认为，当程序员把他的IDE启动成功，Console打印出成功的日志或者弹出首页，一款软件产品就算出世了（打印Hello World不算）。此时的产品我叫它，实产品，第一用户当然也就是程序员。

程序员有很多误区，对于产品的理解就是其一。他们认为的好产品很多时候会狭隘的等同于好代码、好架构。但是这篇文字的上下文里，作为实产品第一用户的程序员，有着责无旁贷的义务，就是代用户体验产品。有人会说我对程序员的要求过分苛刻，连产品的职能都能拿过来做要求。其实你可能误会我的良苦用心了，程序员要不断升级成长，除了编码的本职任务，还需要业务Sense的扩展、适配、DDD，需要运营Sense的排障、hotfix、动态配置，现在又需要用户Sense的体验、诉求。有没有嚼吧出不一样的味道？这些何尝不是程序员

无奈的自保

真不是危言耸听。若然无法对业务的未来走向做出足够的判断，系统架构扩展性不足，打补丁、重构或者重写不早晚还是程序员自己个儿的事嘛？若然不提前考虑投产后的运营保障，展业当天你看吧，啥样稀奇古怪的问题都可能出现，程序员不给自己留个后路，不是修数据就是在hofix的路上。

不敢质疑产品经理的程序员是不合格的。

身边程序员被坑的案例太多了。今天产品说这个业务规则绝对不会变，等你写完代码刚放开键盘的那刻，可能就被告知得变一变了。实诚的程序员直男们，所做的不过是跟产品的五次三番甚至签字画押式的确认，结果不过是一场空，饮恨当场。如此场景我也不止一次的跟开发团队说，不要浪费精力在这种无谓的业务承诺上，身为程序员你该对业务的变化做出灵活的应对，毕竟产品经理也不能预知未来，他的承诺可能只有三天保质期，他也身不由己。或许是老板的意思，或许是用户的意思，而且老板其实不就是一个特殊点的用户而已么？

当你打开某个App的首页，卡顿明显，相信你会不爽的吐槽。但如果这是需要你来实现的，你会说“初期没啥用户，先不做分页了，反正产品也没提，简单点全量查吧！” 对于你来说，实现分页的难度有多大呢？这个讨厌的loading，却可能吓退不少用户，给前端地推带来无尽的难堪。

程序员啊，就算你不是真心为用户考虑的圣人，至少为自己的未来想想，但凡怀疑有坑能提前填上就填上，能提前布局就提前布局，别太实诚了，成么？

我对一个产品用户体验最低标准的理解是，拿着自己开发设计的软件产品，给自己的同学、爱人或者父母看，拿得出手就达标最底线！自己都觉得有点丢人的话，趁早下功夫改掉，别找借口了。

结语

最近心绪一直不太稳定，团队管理、产品设计、系统架构等等都很费神，蛮长时间没静静心沉淀写文了。此题也不过是早上跟爱人聊天的灵光一闪，从动笔到落笔，自觉好像写了点什么又好像什么也没写，有点糟糕，倘若再纠结，此文可能也就去往回收站了，弃之可惜。

另外，昨日刚刚跟团队聊了下用户体验的话题，最后竟然回归到一个原点，“怎么样跟程序员讲明白这个字体为什么要加粗高亮，而不吵架”，我后来给出的结论是“程序员一般都喜欢套设计模式、设计原则，你丢个设计大师Albert Benjamin Calvin Dennis讲过的产品设计十大基本原则，应该比较容易结束讨论”。