十年设计：转任产品经理后我学到的 6 件事

Posted 2023-05-06 Upskill

您是否清楚知道设计师和产品经理这两个岗位的区别呢？

文中的作者，是做了10年设计师，转行做产品经理。他在新角色中面对到一系列全新的挑战，在产品战略方面会更有发言权。作者对这两个角色都有独到的见解，希望能帮助大家理解两者的区别。他渴望分享自己对工作转换的经验和思考，希望能帮助您决定这是否也适合您。

两年前，我从设计转向产品管理（PM）。从实习到管理团队，我做了十年的设计，眼前的管理之路并没有让我感到兴奋。当我没有参与“重大决策”时，例如取消产品线或选择新的战略方向，我会感到沮丧。这让我决定尝试新的方向，同时，我也失去了作为个人贡献者做深层次的、专业的工作的机会。

我一直认为我们“为什么”要构建某样东西这件事和“如何”构建它一样有趣。换句话说，设置问题对我来说和解决问题一样重要。产品开发过程的这部分内容通常由PM承担，而非设计师。

在转变之前，我没有得到来自其他转向PM的设计师的任何战术建议。既然我现在两者都经历过了，虽然我承认我做设计的时间更长，但我想分享我对于这两个角色在日常生活中差异的些许反思。

设计者和PM之间的六大区别

1. 典型工作​

作为一名设计师，我的大部分时间都是不固定的。在我的PM和设计经理的帮助下，我可以维护我的时间。几乎每一天，我都有2-4小时的深度工作时间。按照Cal Newport定义的，深度时间就是指不受打扰，专注于一项认知要求很高的任务的时间。我还可以利用午休散步时间钻研某一问题，也可以和同事聚餐。平均每周，我80%的日程不固定，20%是固定的。

当我变成产品经理时，就反过来了：80%的时间固定，20%的时间灵活。作为一线PM，我出席所有敏捷开发过程以及与之而来的产品交付会议。为了满足客户要求，我每两周都要见一见客户成功部门和销售团队。另外，像客户展示和计划工坊这样的一次性活动会穿插我的月工作表中。为了参加所有这些会议，同时完成本职工作，我需要严格地管理自己的时间。

有产品经理头衔的一个好处是你可以参与任何会议，这是让设计者羡艳的一点。但在你在参加这些重要或不重要的会议的同时，你失去了完整时间。如果要解决难题，你必须让自己能快速进入状态。

2.待办事项

作为一名设计师，我用3-5个项目的简短待办清单开始我的一天。这可能包括“与Ben一起核对注册流程”和“为周四的用户测试创建原型。”大多数日子，我只是按照计划将列表完成。有时任务花费的时间比预期的要长，但我的清单在一天中没有太大变化。

作为PM，我有一个不断增长的待办事项清单，其中包含不断变化的优先事项。挑战在于选择最要紧的事情。例如，有一天，我曾计划为新计划编写产品简介，好让设计师继续下面的工作。但在站会的时候，我听到昨晚的部署打破了我们的销售demo。在下一场客户展示之前修复demo成了我的首要任务。

作为“消防员”，PM被很多事情的变动而牵制。你常常会丢下需要讨论下季度项目的产品战略会议，奔向开发者办公室，把关准备好马上要发布的功能。对于有些人，承担这么多责任令人耳目一新，让事情变得有趣。但对我来说，这些事具有挑战性并令人疲惫。

为了控制我的日常压力水平，我需要更好地管理我的待办事项列表。我开始使用“消除、自动化、委托”框架：

• 消除：是否有可以完全消除的不必要任务？
• 自动化：我可以自动执行哪些重复性任务以节省将来的时间？
• 委任：我可以将哪些任务委托给能够做得更好或者帮我节省时间的人？

3.例行工作

 

每份工作都有例行事务。我把例行事务定义为那些你做起来不愉快但又知道是必须要做的任务。

作为一名设计师，我的主要日常事务就是制作设计规范，包括创立模板、理清状态以及记录功能。这占据大量时间，因为你需要成为细节的坚持者 – 不仅在美学上，而且在功能方面。我花很多时间在选择中徘徊，比如是使用“取消”还是“关闭”这样的字眼。

作为PM，我的日常事务更多。每隔一周，我都会为公司撰写发布说明，为创始人提供产品更新，并为工程师制定冲刺​​目标。我还经常整理积压工作，比如审查客户端调整、bugs修复等并确定优先级。

团队以不同的方式分配日常事务。有些公司有产品专员或项目经理接替PM的任务。有时开发经理会分担一部分工作。但是根据我的经验，PM会承担更多的日常事务，从而能为设计师和工程师腾出更多的时间。

一般来说，设计师的日常工作需要更专注于设计细节。而PM的日常工作需要沟通和项目管理以便保持高效团队。如果要问我，应该当设计师还是PM，我会问你：“什么样的工作对你来说是琐碎的杂事？”。理想情况下，你应该选择那些你不觉得是琐事的工作。

4.团队

作为一名设计师，我认为自己是两支团队的一部分。第一个是我的产品团队：包括我的PM和工程师。这类团队也叫“三角凳”，因为产品、工程、设计需要同努力才能成就一个伟大的产品。我总是能在这类团队中感受到同事情谊，这种情谊只能来自于共同构建产品的努力过程。

我的第二个团队是我的设计团队，即每天坐在我旁边的同事。尽管大家开展不同的项目，但我们能互相激发对方。通过共同的精神和思维方式，我与设计师建立了亲密的关系 – 设计团队是我的部落。

作为PM，我仍然是同一产品团队的一员 – 只是一个不同的分支。然而，我认识到，作为PM，你的产品团队更庞大。它包括其他跨职能部门，例如客户成功、营销、支持和销售。作为PM，我不仅要负责用户体验，还要负责产品业绩，这需要和更多的利益相关者合作。

PM的团队因公司规模而异。在大公司，可能会和同一业务部门的多名PM同仁合作。在小型初创企业，PM可能会和创始人密切合作。然而，在团队中，PM只有一个，这会让PM有时候感到孤立。他们每天花大量的时间和不同的部门同事合作，而设计师和志同道合的设计师们朝夕相处。

5.过程

我早先是被创新设计顾问引荐到设计岗位的。在IDEO我学习了5步设计过程：共情、定义、构思、原型和测试。在Frog Design（美国的一家专业创意设计公司）有三种类型的项目：发现、设计、交付。在进行这些项目的时候，我在设计过程中拼凑自己的观点。作为一名设计师，我总是关注理解问题、定义范围、探索想法、测试假设和交付原型。把设计规范交付给工程师之后，我的项目就结束了，我很快就被带到了一个新的项目。

直到我成为PM之后，我才看到“设计过程”只是产品开发过程的一小部分。发现并确定首先要解决的问题是团队带来设计师之前需要做的。将设计规范移交给工程设计只是构建内容的开始。虽然经常被忽视，但测试产品发布后的效果是最重要的部分之一。

作为PM，我一次处理多个项目 – 通常是在产品开发的不同阶段。例如，我可能一直在与我的设计师一起探讨一个项目的想法，同时与我的工程师一起探讨另一个项目，以及监控我们发布的最后三个项目的分析。同时进行多个项目需要我一天内在不同的产品开发阶段中跳跃。这和设计不同。如果只跟踪1-2个产品，设计师只需要一次专注一个阶段。

6.沟通

当我在IDEO做一名设计实习生时，我了解到有效头脑风暴的一条准则是“以他人的想法为基础”。借用即兴的原则，我们会在别人的想法后面跟上：“是的，并且…”作为设计师，我经常被视为“创意”或“创意人”。但我不相信“孤独的天才创新者”这一说法。伟大的想法来自任何地方，设计师的工作就是为创意提供积极，开放的环境。设计师寻找说“是”的机会，把一个好想法变成一个伟大的想法。这并不意味着伟大的想法没有批评的余地。给予有用的反馈和“是的，并且…”同样重要。

作为PM，我很快学会用“可以，但是……”或“不行，因为……”取代“是的，并且……”。刚上任不到一个月，我不得不对要求竞品功能的客户说“不”，不得不拒绝一个想重新写部分代码的工程师，不得不拒绝试图扩大范围的设计师。为了保持团队目标，说“不”是很有必要的。否则，我们无法发布那些我们认为能够提供最大价值的功能。

高效的产品经理说“不”的频率是说“是”的十倍。个人而言，我发现说“不”更消耗人的精力。我花了大量的精力找到和每一个利益相关者说“不”的最有说服力的方式，同时希望这不会损害我们的关系。有时候，说“不”意味着“现在还不行”；有时候却意味着我们得另辟蹊径。对我来说，保持我对利益相关者的尊重和信任非常重要，因为我未来得和他们共事。

设计师和PM都需要鼓励其他人提出自己的想法，同时也要勇于提出反对意见。关键的区别在于PM有时候必须说“不”。执行产品策略的精髓是选择不做的事情。另一方面，设计师应该说“是”，并以积极的态度来解决问题。

结论

设计师考虑转向产品管理的一个常见原因是想就产品策略获得更大的话语权。我就是其中一个。老实说，作为PM,我的确拥有更多控制权和影响力。我获得了更多信息，与更多人合作，从头到尾管理产品开发流程。

但随之而来的是权衡。我不再有时间在流动状态下工作，无法专注于细节设计，无法享受灵活的日程表。日程表和待办事项的自我管理，以及在不断切换模式下工作变得至关重要。对我来说最难的是从默认情况下说“是”转为说“不”。

在回答这些问题之前，我需要深入了解自己，了解为什么有时候我感到非常精力充沛和充实，但在别的时候却感到压力和疲惫。我相信了解自己的个人特质就能找到自己舒适的位置，因为事实是许多设计师在一定训练和技能培养后能成为很优秀的PM。在选择角色之前，以下是一些可能帮助你找到答案的问题：

• 你理想的工作环境？你不理想的是什么？
• 你的沟通方式是什么？
• 你喜欢如何被管理？
• 什么给你能量？什么消耗你？
• 你想如何为团队带来价值？

无论如何，我很感谢我有机会体验这两种角色。虽然有时候会有压力，但我认为花一年半的时间当PM而不是再当一年半的设计师，从长远来看，会使我成为更好的设计师。谁知道，我可能会为了正确的角色或正确的公司，再次尝试成为PM呢。

 

 

原文链接：

分享丨从事设计10年后转行产品经理，总结6种工作差异

延展文章：

1. 创新案例｜从7个领先标杆看消费品企业如何敏捷创新转型

2. 创新指南｜以“8D能力模型”来发展和提升产品经理能力

3. 是什么造就了一个优秀的产品经理？

更多精彩案例与方案可以访问Runwise创新社区。

​

产品经理最花时间的2件事：异常逻辑梳理与数据处理

冰山：异常逻辑梳理

也许你用了九牛二虎之力，终于把产品的主流程梳理清楚了，但是你看到的只是产品冰山海面上的那10%，剩下的90%是海面下各种情况的异常逻辑。

? 10%的冰山和90%的冰山

任何一个产品功能逻辑，都分为主逻辑和异常逻辑。产品经理们当然要花时间设计精妙的产品主逻辑，构建体验良好的用户使用流程，甚至考虑一个完整的用户闭环。露出水面上10%的冰山，也许会让你心醉；但水面以下90%的冰山，也许会让你心碎。可是没办法呢，产品经理也需要把主逻辑之外的复杂异常逻辑“尽量”梳理清楚。

? 常见的异常逻辑大礼包

常见的异常逻辑有网络错误、新旧功能冲突、任务中断、因延迟导致前端页面与后台逻辑不匹配等。Glen这里帮大家做了简单的总结：

上面简单总结了一些异常逻辑，现实产品设计中遇到的各种异常逻辑远不止这么少。做产品就像完成一件艺术品一样，需要慢慢磨，耐心雕琢。

数据处理

很多童鞋在产品设计时，往往会忽略数据处理的重要性，往往最后会吃大亏。对的，Glen就吃过这个亏，然后被十倍报复了……

? 产品设计的每一个关键步骤都需要数据支持

大部分人，喜欢有创造性的工作，产品经理尤其如此。我们喜欢设计产品的界面、流程、闭环，有时候往往会忽略数据埋点的重要性。产品设计完成后，再返回去给每一个按钮、每一个页面、每一个关键位置标注数据埋点时，我们常常会觉得无聊，因而不重视，因而最后被坑的总是自己。产品设计的每一个关键步骤都需要数据支持，你必须在这些关键节点上做好数据统计埋点。产品上线之后有数据反馈，才能评估产品的品质。切记！

? 无处不在的漏斗

做任何一个产品，都能搭建各种漏斗模型，因为流失和损耗是不可避免的。产品体验理论上可以由几个基础漏斗模型体现：前端用户流程的漏斗模型、后台实现的漏斗模型、服务器交互的漏斗模型。他们中的每一个又可细分出N个小漏斗模型，可以细化到对应的关键数据指标，比如点击转化率、支付转化率等。产品经理们，每天都需要关注这些关键的数据指标，更需要不断完善各种漏斗模型：老的产品需要翻新、新的产品需要建立。

? 数据规范

几乎所有的公司都知道数据的重要性，然而很多公司并没有做好，原因很可能是没有一个统一的数据埋点规范。只有统一化、标准化才能够被良好的管理，不然依然是大道理懂了很多，却依然过不好这一生。很有必要统一一套数据规范，例如：业务-渠道-平台-功能-描述，然后在所有的产品上都按规范进行数据埋点，统一的数据平台就这样被建立起来了。当然统一也有弊端，就是限制了个性化，比如你想跟踪不同的产品版本，如果还是走统一的数据埋点，那会导致两个结果：要么你不敢放量，产品改进后看不出明显的数据反馈；要么你胆儿肥放了很大的用户量，但这样你要承担非常大的改动风险。

这里Glen推荐你一个方法，在规范的数据统计点的后面，再通过页面或者客户端给你增加一个版本段位 Version XXX，然后把版本数据这部分单独上报到另一个地方。（如果你有更好的办法，请告诉我，蟹蟹）