产品打磨之路–坦克变摩托

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 831 天前的主题，其中的信息可能已经有所发展或是发生改变。

Authing 是一款身份云产品，怎么理解呢？大家平时在使用互联网应用或者 SaaS 的时候，通常做的第一件事情就是登录。那么，在登录的过程中，会看到一个登录框，这个登录框是用来记录用户的信息，对企业进行访问控制，而 Authing 就是把这个登录框给 SaaS 出来。

比如说，现在很多的企业在创建应用的时候，往往会想「什么东西该自己做」、「什么东西该外包给其他的公司做」。假如说你在做一个电商程序，你需要支付宝，或者是微信支付，这个时候你往往会选择使用聚合支付软件帮你做支付的功能，Authing 也是一样。

现在，Authing 已经变成了中国的一个云计算基础设施。当我们的服务出现抖动的时候，会影响到在校的学生，在打游戏的玩家，或是在办公室上班的白领。一旦我们出现问题，这些人、厂商或者开发者就会找到我们，要求我们的服务恢复健康状态。身份这个东西，很多人都不关注，但是身份无处不在，这就是 Authing 。

下面让我们详细看一下 Authing 产品的打磨之路。

产品经理要把自己想象成小白

用户思维最核心的点就是产品经理要把自己当成小白用户。所处的位置不同，思考的方式不同，提出的解决方案也不同。如果你是站在产品经理的角度，以上帝视角去设计，那你是只在为自己设计产品。真正站在用户的角度，才能设计出符合用户使用需求的产品。同时在做产品设计的时候，要做到在用户层面向下兼容，当你为小白用户提供了优质的服务。对于其他用户来说就达到了超预期。

用户是“傻”的

我们做用户调研的时候，经常有用户反馈说“这功能是怎么用的，我不明白？”

但是产品经理觉得设计得已经挺清晰了，为什么用户还不明白？这里的概念叫使用成本，当使用成本大于用户理解力的时候，用户就会变少。

我们内部经常会用一个公式计算使用成本：操作数量乘以认知成本的总和是使用成本。大多数的产品经理在设计功能的时候觉得要努力缩短用户的使用路径。路径越短，操作成本可能就越低。但是大多数产品经理都忽略了认知成本，路径越短很有可能导致路径上节点操作数量在增多，导致认知成本指数级的提升。所以并不是路径越短越好，而是在降低用户认知成本的前提下，有效缩短用户行为路径。

用户是“懒”的

大多数用户都希望“能少做一点就少做一点”。其实 B 端产品的功能通常是很复杂的。我们经常看到很多 B 端产品到处都有提示信息，甚至很多产品在我们进入用户界面的时候，会直接跳出全局的信息框 12345 告诉你应该怎么使用。作为真正的用户来说，至少我看到之后，首先是很厌烦，甚至根本不会去看。所以在我们产品内部，我提倡拒绝全局的提示信息，拒绝冒泡的提示信息。因为一是会打断用户的思考；二是即使提示了，用户也不会看的。

其实这样的弹窗隐含了产品经理的心理，就是我都给你这么强的引导提示了，你再不会用你就不能怪我了。在我看来这是产品经理偷懒的方式。所以我们应该思考如何在不增加提示信息的情况下，把功能清晰地展现给用户。

当没有提示信息的时候，我们才会想方设法地优化产品结构、产品术语的表达，让用户尽可能的不看任何提示的情况下就明白你的产品。

用户是盲目的

很多情况下，尤其是作为新手使用一款产品的时候，用户是完全是茫然无措的。

所以要非常重视新手体验。人们对未知的事情都会感到恐惧，有掌控感才会有安全感。所以我们要尽可能在每个功能上都展示它的全流程和当前所在的位置。就像我们看手机地图一样，这样用户不至于迷茫。产品经理要把自己想象成小白。

场景化思维

首先，什么是场景化思维？

所谓的场，就是范围，是一系列客观因素组合而圈定的范围，它包含了时间地点、设备环境、网络环境，甚至当前用户的心境等。

所谓的景，是场当中的存在，它可以是动态的，也可以是静态的，可以是人，也可以是物体。

需求，是依托于场景而存在的，是景在场中互动后的期望。所谓的期望是它预期要达成的目标。

B 端产品的场景化思维和 C 端有很大的区别。B 端的需求大部分情况下是切实存在的，涉及到的角色是非常多的。所以对于 B 端产品来说，要更好地还原需求产生的背景，尽可能便捷高效地帮助用户达成目标。我们不用去猜，我们要更好帮用户降本增效。

明晰功能边界

在场景化思维当中具体执行的时候有两个点，首先要要的是明晰功能边界，需要明确需求所在的场。如果范围场小了，很有可能产品功能不完整；如果大了，要反思是否做了很多不符合当前场景的事情。如果使用成本增加，那用户就会产生困惑。

做需求的两种方式一种叫从外到内，即拿到需求之后，大家开始收集外部信息，看所在的场里景有什么人，然后进行分类抽象，抽象之后制定解决方案开始实施。还有一种叫从内到外，找到需求之后，先不急于去分析收集信息，而是先解构到底需求中最核心的问题是什么。

任何需求都有主要矛盾，我们需要想对应的解决方案。围绕 Core Action 做的一系列操作过程叫 Core Loop 。ToB 也是万变不离其宗--找到核心的问题之后，找到它的解。围绕解慢慢放开约束条件，把场逐渐跟真实的用户需求对齐，最后当场找到了位置，核心的问题得到解决，约束条件就不需要去扩散了。所以所谓的边界就是一系列约束条件。我建议采取先找到 Core Action 再逐步扩散。

面向过程做功能

B 端产品流程往往较长且动态变化，所以 B 端产品更应该面向过程做功能。

我看过很多产品一上来会把各种的名词分类、操作选项都展现给用户，用户想怎么用就可以怎么用，非常灵活，但是灵活背后就导致用户完全不明白如何使用。其中最核心的原因是缺少了过程。因为需求会产生过程，我们对应功能实现的时候也应该有过程，我们需要给用户清晰的过程，去引导他，去层层去递进，去降低用户认知成本。因为很多的情况下，你把所有的功能都铺开的时候，用户是没有办法做决策的，这是非常关键的一点。

具体做法在我们内部，是强调用户旅程。

■图：用户旅程阶段示意

以我们的产品为例，每次写 PRD 的时候，都会嵌一套用户旅程，查看是否完全按照用户旅程去梳理了需求。好处是梳理完之后很多情况下我们是可以预判用户的下一步动作。可以让整个功能变得更加的贴心。

在做产品的时候，需要关联的、整体的、动态的去审视问题。全局思维看似很虚。但是如果作为产品负责人是必须考虑的，只有在大局上去看待问题，才能更加清晰地明确每个子功能要做的事情，去做通盘考虑的时候才能有主次。

这样在做功能迭代的时候就可以做到心里有数，坐实不慌，团队内部的小伙伴能够思维统一，避免单兵作战。

何系统都有三个构建，第一是要素，第二是连接，第三是目标。每个产品无论大小，都能形成自己的系统。针对系统构建的划分的不同类型要有一些不同的侧重。

1 、要素型功能：可拆解

当我们做平台型产品的时候，是否可以先把自己作为需求方服务得很好？如果可以的话，相信很多跟我们自己有共同需求的客户，也会受益于我们的解决方案。

2 、连接型功能：可拓展

产品能不能实现指数规模的价值提升，去完全依赖扩展性。因为要素型功能主要在做加法，连接型的功能才能做乘法，充分发挥连接器的作用，产生网络效应。

3 、目标型功能：可迭代

在 Authing 内部，比如有单点登录、多租户、同步中心权限管理、用户管理，这些以帮助用户达成目标而实现的功能。针对这种类型功能要做到可迭代。

拥有减法思维，才能做出优秀的产品。比如 Mac 电脑可以少一根线，再如特斯拉等产品，都在不断地去做减法为用户减负。

做加法其实是特别容易的，无外乎再加个按钮或者加个页面。但做减法是很难的，要不断地逼问自己说能不能更少一点，小到字符，大到页面，甚至功能是否可以砍掉。

但减法并不是刻意不去做功能。为了简单而刻意抛弃功能的产品是走不远的。B 端产品来说更是如此，功能的完备性是企业客户的首选，客户并不会因为功能少而选你，而首先要考虑的因素是你的产品能帮我达成既定的目标。

■图为 Authing

如何判断多还是少？可以从三个维度考虑：

1. 成本与收益：减少用户的理解和操作成本，增多的是产品目标的收益；站在产品的角度去衡量，少的是用户的抱怨和指责，同时又少了一些程序员的投入。

2. 信噪比：减少了无用的噪音，增多了有效信息。在单位时间内用户在操作产品的时候，处理噪音的时间越少，肯定用来吸收信息的时间越多。噪音和信息的区分来自与业务目标的关联度，关联度越大，离核心诉求越近，越是信息。

3. 通用性：功能越单一通用性越强。比如登录组件，相对功能丰富的管理后台来说它的功能是很单一的，因为它只做了登录这一件事。在通用性没做起来之前，大家要尽量克制，不要狂加功能。功能加的越多可能通用性越差，同时核心的功能又没做好。

产品减法原则

1 、奥卡姆剃刀（三刀流）

第一刀：做需求之前自我问：“这个需求可不可以不做？能不能直接砍掉？某些需求通过其他要素型功能的组合或者连接就可以完成，不需要去增加新的实体，这样可能会砍掉 50% 的需求。

第二刀：“时刻警惕新增的实体”，也就是新的概念，新的流程，新的页面，甚至可能小到新的按钮，这都是实体。新的实体增加得越多，用户的认知成本越大，产品也会变得越来越臃肿。

第三刀：在做完方案之后，我会在心里对着他们每个小的功能点尝试着去砍一刀，砍掉之后看对于整个产品有没有什么变化，如果没有什么变化、用户也能理解，那可能这个功能就并没有需求。

2 、实操的 peace 原则，研发背景的小伙伴可能都听过 keep it simple and stupid 这句话。

我之前在写代码的时候一直推崇，代码越简单稳定性越强，可读性也越强。我做产品之后也一直秉承着相同的理念。对于产品来说最重要一点就是警惕复杂。大部分情况下，需求是并不复杂的，用户的需求都很直接。功能复杂很有可能是产品经理没有想清楚。针对复杂的功能可以优先拆分步骤，确定核心的功能指标，通过功能步骤的组合达成最终目标。虽然功能复杂，但每一步都很精简。

本文详细讲述了 Authing 产品方法论，包括以下四个方面：

如何站在用户角度设计功能
如何通过用户旅程设计功能
如何通过全局化思维设计功能
如何学会给功能做减法

未来，Authing 将一直秉承着“连接全球人与应用”的使命，进一步开拓身份云技术，持续为各行各业的客户提供安全、现代化、可信任、可复用的身份基础设施，致力于成为全球最大的生产力科技公司。

活动预告

9 月 24 日下午，声网开发者创业讲堂 • 第 5 期将以「技术创业者如何做好技术团队管理？」为题，邀请翟佳、杨帆、史海峰三位资深的技术专家为大家带来精彩的分享，欢迎感兴趣的伙伴报名～

活动报名微信扫描下方二维码或点击链接即可报名： https://www.huodongxing.com/event/7665949006823

声网创业讲堂交流群

当下是一个人人可创业的时代，对技术人来说，更是一个创业友好的时代。如果你懂技术，会比其他人更容易将自己的创业想法和梦想付诸实践。但创业意味着要从 0 到 1 ，意味着要持续的创造和创新，意味着创业者和团队需要不断的成长和突破。只有这样才能打造出满足市场需求的、有价值的产品，逐渐形成企业的优势和壁垒，成长为一家成熟的企业。

声网关注有创新能力、开发能力和创业意向的开发者，并希望为开发者提供相应的支持和服务。为此，我们推出了“声网开发者创业讲堂”系列创业分享，以便为大家在成长和创业路上提供更多的帮助。欢迎扫码申请加入我们的创业开发者社群！