Product Management for Autonomous Driving Platform

In addition to defining Operational Design Domains (ODDs) for autonomous trucks, a significant portion of product management work at autonomous driving companies involves identifying and improving development and iteration processes. Product managers often utilize software solutions for these tasks. In this article, we focus on the product management methodology for efficient platform development.

The methodology is for engineering efficiency products, meaning the scope is usually designing products for users that we are paying for (e.g., the triage team, algo test engineers), not for general 2B or 2C products.

Methodologies#

The best “new platform” is “no platform”
The product management and design of efficiency products should only be guided by efficiency
The design of efficiency products should be from top to bottom
Find primary pain points for the system first, and then for users
Design platforms based on “nodes and triggers”
Users should be consistently educated

A well-designed efficiency platform should have:

Quantifiable efficiency metrics
Clear information visualization and synchronization capabilities
Clear status visualization and synchronization capabilities
Linear and well-defined usage processes
Clear technical boundaries

Executions#

The Best “New Platform” Is “No Platform”#

Utilizing mature algorithms or programs to solve problems is often faster than relying on human intervention. The primary focus should be on exploring and devising solutions from a technical perspective, defining and pushing technical boundaries, rather than designing solutions based on user and developer needs and experiences.

Tools should minimize human intervention instead of adding to it. While “creating a new platform to solve this problem” may seem like the simplest and most direct solution, it is not always the best one. Understanding the essence of the problem, defining its nature (a product problem or a process problem?), and determining its importance (using the important-urgent rule) should always be the first tasks for product managers and designers.

Product Management for Efficiency Platforms Should Only Be Guided by Efficiency#

Driven by efficiency: as mentioned earlier, we hope to solve problems in a systematic and automatic way. Therefore, when a product is identified as necessary and has to be operated by engineers, our focus should be on:

Thinking about the exit strategy of the product, meaning the ultimate automation of the product
Minimizing the time users spend using the product. The simplest way to measure this is through the efficiency with which users complete a task.

Solely driven by efficiency: during the product management and design of internal products, numerous factors can influence the judgment of product managers and designers. These factors may include the product’s ease of use, existing user habits, visual aesthetics, or even the whims of higher-ups. Designers and product managers need to remain focused, and the most effective way to guide product requirements and design is by prioritizing efficiency. Among all these factors, efficiency is the most easily quantifiable, verifiable, and refutable aspect.

Measuring efficiency:

Time required for users to complete a unit task using the product (time spent operating the tool by humans).
Time required for users to communicate with others to complete a unit task (time spent interacting with other humans to finish a task).
Troubleshooting time required for users to complete a unit task.
Machine time required for users to complete a unit task (time needed for the machine to process the task).

The Design of Efficiency Products Should Be from Top to Bottom#

When discussing efficiency, it should always focus on the efficiency of the entire system, not just a single tool. Even if Gaea Builder is outstanding, if the map CI is slow, the efficiency of map publishing will remain low. To genuinely define and enhance system efficiency, it is necessary to:

Have a thorough understanding of the system itself
Define goals and milestones from top to bottom, and establish product boundaries and missions.

A common mistake made by product managers and designers unfamiliar with the technical details of a system is trying to improve efficiency based on the interface. “Improving efficiency based on the interface” means that the design and product team adopts the users’ mental model and attempts to identify product and process issues from the user’s perspective. This approach can create an ultimate tool (in terms of ease of use), but not ultimate efficiency. Researching users should be the last step in design and product management, while understanding and defining tool and process goals should be the first step.

A key reason for top-down design is also to define the boundary. Defining the boundaries of each tool is crucial for tools that form a toolchain. Due to the continuous improvement and change in technical capabilities, product management and tool design will always be dynamic. If we keep adding features to a single tool or product, which is usually the most intuitive way to do product management, we are likely to build a monolith at the end of the day or year.

Primary Pain Points for the System First, and Then for Users#

By focusing on pain points based on processes and the autonomous driving system, we can ensure:

A “top-down design” that remains unaffected by user perspectives
An accurate understanding of product boundaries

Identifying pain points based on users is always the most direct and straightforward way to summarize results. Designers and product managers tend to rely on this simple and effective method, forsaking system-level thinking. After long-term product management of tools based on functionality, tools are prone to becoming monolithic, since functionality cannot define product boundaries.

Design Products with the “Node-Trigger” Method#

Products with complex interfaces, such as HMI, can easily cause product managers and designers to lose direction and focus on refining individual functions. As mentioned earlier, the sole goal of tools is to improve users’ task completion efficiency (broadly defined efficiency, rather than efficiency within the tool). A tool design model based on a defined process for moving forward is necessary.

The node-trigger model:

Assume that tasks throughout the process can be completed by machines.
Define major nodes that can and cannot be completed by machines.
Define nodes that require human intervention.
Define the interaction method for human intervention triggers.

The node and trigger method can ensure that 1) efficiency goals are consistently emphasized, 2) the user’s usage process is as linear as possible, and 3) the information visualization of the system can always be considered one of the highest priorities.

Creating Synergy with Business Users#

The best operational practice of efficiency products should be actively and passively defined to reduce learning costs and minimize the possibility of errors. Product managers and designers of efficiency products are responsible for defining the user’s method of use, especially for non-technical background users, such as TEs and Triagers (Ant users). For these users, new design specifications and usage methods require continuous communication and education by the product team to ensure users have sufficient awareness of the product and that their usage path aligns with the design.

For technically skilled users, such as algorithm developers (Rhino users), the challenge of aligning design and user involves changing the user’s existing habits. Successful operational changes often rely on product design consistency. On one hand, the product and design team must have well-established design system support and convince users to try more efficient interaction methods. On the other hand, products and users need to establish sufficient trust to help execute the design. Both of these aspects require education and communication with users to ensure implementation.

A Little Bit More: Contrasting 2B/Internal Efficiency Products with 2C Products#

For most 2C products, retention is crucial. The critical feedback indicator for retention is the amount of time users spend using the product. For internet apps that can be considered “tools,” the key is to keep users in the tool for as long as possible.

However, the vision for internal efficiency products is different, and TuSimple product managers and designers sometimes overlook this. In this case, a clearly defined methodology and goal are particularly important, with creativity not always being the top priority in design.

2C products emphasize breakthroughs by using a single set of features or communities to solve a set of user scenarios or pain points, attract users, and increase retention (GMV for e-commerce). They then use the user base to discover and address more pain points. This approach is not entirely applicable to the design of internal efficiency products and processes. The “pain surface,” or the pain points of the entire process from start to finish, is more important than individual “pain points” for internal efficiency products. The object of this “pain surface” is the output of the product, rather than the users, as in 2C or 2B products.

Lastly, improving the user experience of internal efficiency products can be a misleading proposition. When discussing user experience, we are considering the difference between the predetermined user usage method and the actual usage method of untrained users. For 2C products, this difference can usually be bridged through intuitive product design, while for internal efficiency products, it can be minimized through process management. Is simple and easy-to-use interaction still necessary for internal efficiency products? It is still necessary, but the threshold can be lower compared to 2C products in certain scenarios.

在自动驾驶公司，除了为自动驾驶卡车定义运行设计域（ODD）之外，产品管理工作中相当大的一部分，在于发现并改进研发与迭代流程。产品经理通常会借助软件方案来完成这类工作。本文聚焦于效率平台研发中的产品管理方法论。

这套方法论面向工程效率产品，也就是说，讨论范围通常是为公司自己付薪水的用户（例如 triage 团队、算法测试工程师）设计产品，而不是通用的 2B 或 2C 产品。

方法论#

最好的「新平台」是「没有平台」
效率产品的产品管理与设计只应以效率为导向
效率产品的设计应当自上而下
先找系统的主要痛点，再找用户的痛点
基于「节点与触发器」设计平台
应当持续地对用户进行教育

一个设计良好的效率平台应当具备：

可量化的效率指标
清晰的信息可视化与同步能力
清晰的状态可视化与同步能力
线性且定义明确的使用流程
清晰的技术边界

执行#

最好的「新平台」是「没有平台」#

用成熟的算法或程序来解决问题，往往比依赖人工干预更快。工作重心应当放在从技术角度探索和构思解决方案、定义并推进技术边界上，而不是基于用户和开发者的需求与体验来设计方案。

工具应当尽量减少人工干预，而不是增加人工干预。「做一个新平台来解决这个问题」看似最简单直接，却未必是最优解。理解问题的本质、界定问题的性质（是产品问题还是流程问题？）、判断问题的重要性（运用重要紧急四象限），永远应该是产品经理和设计师的第一项工作。

效率平台的产品管理只应以效率为导向#

以效率为驱动：如前所述，我们希望以系统化、自动化的方式解决问题。因此，当一个产品被确认为必要、且必须由工程师来操作时，我们的关注点应当是：

思考产品的退出策略，也就是产品的最终自动化
最小化用户使用产品的时间。衡量这一点最简单的方式，就是看用户完成任务的效率。

只以效率为驱动：在内部产品的产品管理与设计过程中，会有诸多因素影响产品经理和设计师的判断，比如产品的易用性、用户的既有习惯、视觉美感，甚至上级的一时兴起。设计师和产品经理需要保持专注，而引导产品需求与设计最有效的方式，就是把效率放在首位。在所有这些因素中，效率是最容易量化、最容易验证、也最容易被证伪的一个。

效率的衡量：

用户使用产品完成单位任务所需的时间（人操作工具所花的时间）。
用户为完成单位任务而与他人沟通所需的时间（为完成任务与其他人交互所花的时间）。
用户完成单位任务所需的排查问题的时间。
用户完成单位任务所需的机器时间（机器处理该任务所需的时间）。

效率产品的设计应当自上而下#

讨论效率时，永远应该着眼于整个系统的效率，而不只是单个工具。即便 Gaea Builder 再出色，如果地图 CI 很慢，地图发布的效率依然会很低。要真正定义并提升系统效率，需要：

对系统本身有透彻的理解
自上而下地定义目标与里程碑，并确立产品的边界与使命。

不熟悉系统技术细节的产品经理和设计师常犯的一个错误，是试图基于界面来提升效率。「基于界面提升效率」指的是设计与产品团队采用用户的心智模型，尝试从用户视角去发现产品和流程的问题。这种方式可以做出（易用性意义上的）极致工具，却做不出极致的效率。用户调研应该是设计与产品管理的最后一步，而理解并定义工具与流程的目标才是第一步。

自上而下设计的另一个关键原因，是为了定义边界。对于构成一条工具链的各个工具而言，界定每个工具的边界至关重要。由于技术能力在持续改进和变化，产品管理和工具设计将始终处于动态之中。如果我们不断往单个工具或产品上叠加功能（这通常是做产品管理最直觉的方式），那么到头来（也许是某一天，也许是某一年），我们很可能会造出一个巨石应用。

先找系统的主要痛点，再找用户的痛点#

基于流程和自动驾驶系统本身来关注痛点，可以确保：

「自上而下的设计」不被用户视角所左右
对产品边界的准确理解

基于用户来识别痛点，永远是总结结论最直接、最省事的方式。设计师和产品经理容易依赖这种简单有效的方法，从而放弃系统层面的思考。长期基于功能来做工具的产品管理之后，工具很容易走向巨石化，因为功能无法定义产品边界。

用「节点与触发器」方法设计产品#

界面复杂的产品（例如 HMI）很容易让产品经理和设计师迷失方向，陷入对单个功能的打磨。如前所述，工具的唯一目标是提升用户完成任务的效率（广义的效率，而不是工具内部的效率）。因此，需要一个基于既定流程、持续向前推进的工具设计模型。

「节点与触发器」模型：

假设全流程中的任务都可以由机器完成。
定义哪些主要节点可以由机器完成、哪些不能。
定义需要人工干预的节点。
定义人工干预触发器的交互方式。

「节点与触发器」方法可以确保：1）效率目标被持续强调；2）用户的使用流程尽可能线性；3）系统的信息可视化始终被视为最高优先级之一。

与业务用户形成合力#

效率产品的最佳操作实践应当被主动和被动地定义出来，以降低学习成本、尽量减少出错的可能。效率产品的产品经理和设计师有责任定义用户的使用方式，尤其是面向非技术背景的用户，例如 TE 和 Triager（Ant 的用户）。对这些用户而言，新的设计规范和使用方式需要产品团队持续地沟通与教育，以确保用户对产品有足够的认知，且他们的使用路径与设计保持一致。

而对于技术能力较强的用户，例如算法开发者（Rhino 的用户），让设计与用户对齐的挑战在于改变用户的既有习惯。操作方式的成功改变往往依赖于产品设计的一致性。一方面，产品与设计团队必须有成熟的设计系统作支撑，并说服用户尝试更高效的交互方式；另一方面，产品与用户之间需要建立足够的信任，来帮助设计落地。这两方面都需要通过对用户的教育和沟通来确保执行。

再多说一点：2B/内部效率产品与 2C 产品的对比#

对大多数 2C 产品来说，留存至关重要。而留存的关键反馈指标，是用户使用产品的时长。对于可以被视作「工具」的互联网应用，关键就在于让用户在工具里停留得越久越好。

然而，内部效率产品的愿景与此不同，TuSimple 的产品经理和设计师有时会忽略这一点。在这种情况下，清晰定义的方法论和目标就显得尤为重要，创意在设计中并不总是第一优先级。

2C 产品强调突破：用单独一组功能或社区去解决一组用户场景或痛点，以此吸引用户、提升留存（电商则是 GMV），然后再依托用户基数去发现并解决更多痛点。这种思路并不完全适用于内部效率产品和流程的设计。对内部效率产品而言，「痛面」，也就是从头到尾整个流程的痛点，比单个「痛点」更重要。这个「痛面」的对象是产品的产出，而不是像 2C 或 2B 产品那样以用户为对象。

最后，「提升内部效率产品的用户体验」可能是一个有误导性的命题。讨论用户体验时，我们考量的是预设的用户使用方式与未经培训的用户的实际使用方式之间的差距。对 2C 产品来说，这个差距通常可以通过直觉化的产品设计来弥合；而对内部效率产品来说，它可以通过流程管理来缩小。那么，内部效率产品还需要简单易用的交互吗？仍然需要，但与 2C 产品相比，在某些场景下对它的要求可以放低一些。