从设计师转岗到产品经理，6个意想不到的工作差异

2019-02-21 16:01:00

设计师和产品经理这两个不同的工作岗位，有什么你想不到的工作差异呢？

很多设计师对产品经理这个岗位充满好奇，不知道他们每天都在干嘛？觉得他们就是一群闲人，每天就只用排需求表，分配任务，开完讨论，最后只说不干。而产品经理又经常抱怨自己太忙，自嘲自己是“产品狗”，每天有忙不完的事。

设计师与产品之间互不理解，发生矛盾的事常有发生。

作为一名设计师，我对于产品的日常也是挺好奇的，所以我找到了这篇文章，希望对产品日常感到疑惑或者想转岗的朋友能有一些启发。

译文：

超级产品经理

两年前，我从设计转岗到产品经理（PM）。在设计行业打拼了10年，我从一名实习生一路做到了团队领导，但我对未来的管理之道并不感到兴奋。我会怀念我曾经作为一个普通员工时在产品一线所参与的工作。我也会因为没有参与到产品经理们所做的“重大决策”，例如突然取消产品上线或者选择新的战略方向时而感到沮丧。

我经常会发现“why”和“how”一样有趣，换句话说，发现问题和解决问题对我来说一样重要。产品开发过程的这部分工作通常都是由PM来管理的，而不是设计师。

在转换身份之前，我没有从其他设计师转行产品那里获得任何实战经验。现在，在实践了这两个角色之后（虽然设计工作的经历会更长），我觉得可以分享一下我对这两个不同工作岗位日常生活中的一些不同感受和思考。

设计师与产品经理之间的6点差异：

1. 每周工作日常

超级产品经理

作为一名设计师，我每周的工作计划都没有固定时间安排，我的工作计划来自于产品经理和设计领导的需求。每天，我只有大概2-4个小时是深度工作时间，正如Cal Newport说的那样，把时间专注在“认知要求高的任务”上。但平均每周算下来，我的80%时间是不受自己控制的，只有20%的时间能真正自己安排。

作为产品经理，我的时间则恰好相反，80%的时间是确定的，只有20%的时间不确定。作为一线产品经理，我参加了敏捷开发过程中的所有产品交付会议：站立会、sprint规划会议、sprint启动会议还有项目回顾会议（译者注：sprint是敏捷项目管理的一种方式，具体的内容可以自行查阅资料，我就不展开说了）。

为了满足客户的需求，我每两周还需要查看用户数据和业绩情况。此外，像客户演示和规划研讨会这样的一次性活动会出现在我的整个月的日历上。为了参加所有这些会议，同时还要完成自己的工作，我需要非常严格的管理好自己的时间。

拥有“产品经理”头衔的一个好处是，你可以有机会参与到任何产品会议中去，并能发表自己的见解——这通常是设计师们所渴望的，但是你可能会因为参加那一堆的会议而失去不受打扰的时间。设计师想要参与到整个产品的规划和推动相比产品就显得困难的多。

2. 任务清单

超级产品经理

作为一名设计师，我每天的工作事项大概就是3-5件，这可能是包括“和Ben一起核对注册流程”或者是“为周四的用户测试设计一个原型”这类的需求。大多数时候，我只做简单的执行就可以了，虽然有时候花费的时间会超过预期，但其实总体来说是没有太多变化。

作为一个产品经理，我会有一个不断增长的待办事项列表，优先级也是在不断的变化，最大的挑战就在于如何判断哪个事项优先级最高。例如：有一天我的计划是为产品写一篇产品说明，为了方便设计师更好的理解。但我又突然听说，昨晚的软件部署出了问题无法完成销售演示，那在下一次客户演示之前修复演示问题就成了我的首要任务。

作为一名“救火队员”，产品经理需要进行大量的工作内容切换。在产品决策会议上，还在探讨下一个季度的项目，然后又马上对接到开发那边，需要发布新的功能。对一些人来说，不断接触到新的工作内容，会让工作本身变得很有趣。但对我来说，我却发现这其实很有挑战性，也很累。

为了不让自己的压力过大，我会尝试使用一些更好的方式管理自己的待办事项清单。比如我开始使用一项事务管理框架：“筛选、自动化、委派”。

筛选：是否有一些非必要的任务可以删除。
自动化：哪些重复性的工作可以通过技术手段或者模板自动完成的。
委派：哪些任务是不需要自己特别注意，可以委派给更合适的人来做的。

3. 杂活

超级产品经理

每个工作都有一些杂活，我把杂活定义为那些你可能觉得不愉快，但是又必须要做的例行任务。

作为一名设计师，我的主要杂活是制定设计规范，这包括设计一些模板框架，定义每个交互状态，以及对接开发还原落地等。这需要花费大量的时间，因为需要把握产品的细节——不仅在美学上，在功能上也是如此。我会花很大时间考虑各种选择，比如一个按钮的文案是用“取消”还是“关闭”。

作为一个产品经理，我的杂活清单要长的多。每隔一周，我都需要为公司写发布说明，为产品编写更新内容，为开发编写sprint需求目标。我还需要定期整理待办事项列表，检查并确定客户端升级时间，bug单，以及各种事项的优先级。

不同的团队对这些杂活有不同的分配方式。有些公司有产品专家或者项目经理，他们负责分担一部分项目工作。但根据我自己的经验来说，产品经理通常会把更多的杂活自己揽下来，以省出更多的时间给到开发和设计师。

一般来说，设计师的杂活是去更多的关注设计细节，而产品经理的杂活则是需要沟通和项目管理技巧来组成一支高效的团队。为了能得到关于你应该成为设计师还是产品经理的直觉反应，我喜欢问：“这些杂活对你来说，是一件苦差事吗？”。理想情况下，对于觉得自己做的杂活也是有收获的人来说，杂活并不是杂。

4. 团队

超级产品经理

作为设计师，我认为自己是两个团队的成员。第一个是我的产品团队，我的产品经理和开发。这三者通常被称为“铁三角”，因为产品、开发和设计需要通力合作，才能实现一个伟大的产品战略。我一直觉得和这种类型的团队有一种亲密的友情，这种友情只来自于共同开发一个产品时的起起落落。

我的第二个团队是我的设计团队，我每天都坐在他们旁边。这让我们能够相互交流想法，即使我们是在不同的项目上工作。通过我们工作的专业和思维方式，我感到设计师之间的那种亲密关系，设计就是其中的纽带。

作为产品经理，我只是同一个产品团队中的一员，然而，我现在知道作为一名产品，自己的产品团队更大。这包括很多跨功能的组织，如果客户管理、市场营销、支持部门和销售团队。作为一名产品，我不仅要负责用户推广，还要负责产品的业务性能，这会涉及到更多跨部门的合作。

一个产品团队规模因公司而异。在大公司，在一个业务单元中有多个产品经理，产品经理可能也需要与其他产品配合一起工作。在小公司，产品经理可能是会与创始人一起合作。然而，产品通常只是管理产品，他们有时可能会感到孤立和孤独。他们把一天中的大部分时间都花在各种不同的功能上，而设计师一天的时间起码是坐在设计师中间一起工作。

5. 流程

超级产品经理

我第一次接触设计是在一家设计咨询公司。那时候，在IDEO，我学习了做设计的5个步骤：共情、定义、构思、原型和测试。在frog design，会有三种项目步骤：发现、设计和交付。通过这些经历，我对设计过程有了自己的看法。

作为一名设计师，我总是专注于理解问题，定义范围，探索想法，验证假设，最后交付原型。在我把设计规范给到开发后，一般来说我的项目就结束了，我很快又会加入到一个新的项目中去。

直到我成为产品经理，我才发现“设计过程”只是产品开发环节中的一小部分。在团队引入设计师之前，就已经有很多问题需要解决并需要排上优先级。把设计规范交给开发仅仅是一个开始，尽管经常被忽略，但是在产品发布之后的数据是最重要的部分之一。

作为一名产品经理，在产品开发的不同阶段，我经常需要同时处理多个项目。例如：我可能会与设计师探讨一个项目想法，但同时又在与开发会讨论另一个项目的问题。保持多个项目并行，并需要在不同产品的不同阶段反复切换思维，这与设计不同，在设计中我可以是一次只专注于一个项目阶段。

6. 沟通

超级产品经理

我在IDEO做设计实习生的时候，我学到了一条有效头脑风暴的规则：“灵感建立在他人的想法之上”。我们会借用一个即兴表演原则，用“是的……”这个短语，后面跟着一些建立在别人想法上的东西。

作为一名设计师，我经常被视为“有创意“或者”有想法的人”，我不相信谁是可以完全独创的，伟大的想法来自任何地方。设计师的工作就是为创意提供积极，开放的环境，设计师会将一个不错的点子变成一个非常棒的创意。这并非是说，设计师不擅长说否定意见，而是指这样的联想方式更能激发出好的创意。

作为一名产品经理，我很快就学会了用“是的，但是……”或者“不，因为……”来代替“是的，并且……”。

在我工作的第一个月里，我不得不对一个要求加上竞品功能的客户说“不”，对一个想要重写部分代码库的开发说“不”，对试图做大量修改的设计师说“不”。说“不”对于保证团队对目标的专注是非常必要的，否则，我们就无法交付我们认为最有价值的功能。

最厉害的产品经理说“不”的次数是说“是”的10倍，就我个人而言，我发现说“不”常常让人精疲力竭。我花了很多精力去寻找合适的理由说服每个利益相关者说“不”，同时还希望能尽可能不伤害我们之间的关系。有时可能会说“这个阶段先不做”，然后详细的解释为什么我们要做别的事情。对我来说，保持利益相关者的尊重和信任很重要，因为我知道未来我还是得继续与他们合作。

设计师和产品都需要多鼓励其他人向他们提出想法和要求，同时也能够分享一些相反的意见。关键的区别在于产品很多时候都需要说“不”，执行产品战略的本质是需要选择不做什么。另一方面，设计师应该多说“是”，并以积极的“我能行”的态度来解决问题。