有图有排版 Medium 好读版：http://a0.pise.pw/PFNJD
【PM伙伴攻略】如何与行销团队合作？沟通产品价值的好伙伴！
行销领域（Marketing）比起软件产品领域算是存在比较久、方法论也较多的学问，随着软件与网络产业的蓬勃发展，行销团队内的职务分工也愈来愈多样化，包含品牌行销、数位行销、内容行销、广告投放、媒体公关、社群经营、活动企划、市场分析…等工作内容都可能被包含在行销团队内。
在我待过的几个团队里，业务团队主要面向尚未被开发的未知新用户（案子谈成后可能会转给 AM 或客服继续维持客户关系），客服主要服务已经/曾经跟我们有所关联的已知用户，行销则是未知用户、已知用户的部分都要包 — — 想办法找到还不认识我们的用户，让他们初步看见我们这个品牌、产品、服务；同时维护已知用户的社群、关注目前的口碑，持续将价值传达给用户。
▍共同目标：获取新用户、留住旧用户
产品与行销团队有共同的大目标 — — 获取新用户、留住旧用户，当然还有后续的变现，然而关注的角度、阶段与定义可能略微不同。
共同的目标、不同的指标
行销团队看“获取新用户”的角度可能在于广告点击、进入着陆页（Landing Page）的转换率；而产品团队在意的可能是从着陆页上转换为注册会员的转换率，甚至是完成第一个新手任务（Onboarding Task）的转换率。两者的大方向都是“获取新用户”，若能完美串在一起，整个优化流程就会非常顺畅。
但若只过度关注自己那一方的指标，或是不理解产品目前的阶段和适用性，就可能会因为彼此数据互为分子分母而造成对方的指标数据被影响。
举例来说：行销想到了一个比较极端的产品使用案例（Use Case）而且确实敏锐的嗅到这是市场上许多人有需求的功能、使用情境，因此投出去的广告正中红心，创造非常多点击与着陆的用户。
状况好的情形是用户都确实注册了（注册人数 up up）但若最后他们在试用之后发现不适用而没有留存下来、没有成为付费用户，这笔行销预算尽管达成了行销团队的目标、却没有达到产品团队的目标。
状况差的情况是注册在浏览着陆页、功能介绍等页面后发现不敷需求，因此连转换为注册会员都没有，产品团队在这个情况下就会很明显地看到自己负责的注册转换率下降了。
这就要回归到公司的整体商业目标、产品的整体目标为何，如果公司在意的是注册人数，若是广告转换率提升、注册转换率下降，但是总体注册人数是上升的，就不能说这是个不好或无效的行销策略。
共同的目标、不同的思维
而在空间资源非常有限的 Mobile 产品内锁下重要版面进行行销活动，导致使用者体验变差也是我常听到身边 PM 提出的问题 — — 行销认为放上吸引人的广告 banner 对商业目标是好的、产品认为放上用户需要的功能在这个版位上才是对长远商业目标有益的。
这个问题的答案没有谁对谁错，只是心态与思维的不同。行销的工作是主动沟通产品价值、产品的工作则是被动了解用户需求来做出回应，两边其实是相辅相成才能让产品成长的。
▍工作项目：行销团队作为需求方
1. 官方网站、活动页面、SEO
我在加入某个团队时，第一个接到的案子就是改版官方网站。当时的老板说：就当作你碰 Core Product 前的小练习吧！
官方网站上的内容、对外沟通的方式、产品形象，通常是由行销团队来负责（有些团队目前也衍伸出 UX Writer 这个职位），简单的官方网站可能就只是一页式的着陆页，完整一点的则包含公司介绍、功能介绍、成功案例、费用说明、联络页面…等等。这大大小小的地方有很多地方可以优化，更遑论充满创意的行销团队有时候会有新的页面、区块、互动方式想要增加。
活动页面的部分则是像前面提到，在投放广告给不同的目标用户（Target Audience, TA）时会让他们前往不同的着陆页，上面主打的会是不同的使用情境；或是在有特别节日、特别折扣活动时要使用的着陆页。
最后一个很重要的就是 SEO（Search Engine Optimization），这部分改动的需求跟频率也满大的，有些团队会有专案小组（包含 PM 或行销）专门来处理这方面的优化。
2. 串接广告工具、数据分析与 A/B Testing 的需求
找到陌生的新用户、投放合适的广告并引导他们成为产品用户是行销很重要的工作，要能够优化整个工作流程就需要将广告工具串连在产品上，才能好好地透过量化的数据分析来改变行销策略与广告投放策略。行销团队也会做 A/B Testitng 来找出最合适的价值沟通方式。
工具举例：Facebook Pixel、Google Analytics、Google Tag Manager、Kissmetrics、Mixpanel、Amplitude、Firebase、Optimizely … 等等。
3. 串接、开发其他行销沟通工具
前面提到，行销的工作是主动沟通产品价值、产品的工作则是被动了解用户需求来做出回应，有许多其他工具其实是能帮助行销团队沟通价值的，例如部落格、推播系统、公告系统、EDM…等等。
这部分有些团队会选择自己开发，但我的建议是在团队资源还没那么充足的时候，串接和使用第三方的系统是比较轻量型的做法，一方面行销团队在使用的时候可以尝试的功能比较多、另一方面是若最终公司还是想要自己做，就能更了解行销团队真正需要的功能与使用情境为何，不会开发出无用的内部工具。
工具举例：部落格可以使用第三方 CMS（Content Management System） WordPress、Strapi、HubSpot；推播系统与公告系统可以跟客服团队合作 Intercom、Reamaze、Zendesk、CleverTap；EDM 可以使用 MailChimp。
▍工作项目：行销团队作为供给方
以上行销作为需求方算是最常见的状况，但行销团队对于产品团队来说也有作为供给方的时候！
1. 竞品与市场研究
尽管角度与产品团队所做的研究会有些为不同，但还是很有参考价值的。当市场上出现了新的竞品、新的需求时，行销团队通常会是第一个敏锐观察到的。
2. 社群回馈
在跟行销团队接触的过程中，我发现我们做的事情有时候是略为重叠的，只是目标跟着重的点不一样，或是我们称呼这件事的方式不同
举例来说，有些行销团队会做焦点访谈（Focus Group）、VoC（Voice of Customer）的研究，其实就跟产品团队在做使用者研究的概念是相通的。
有些行销团队做线下的社群经营，目标可能是维护跟社群的关系、让社群之间彼此有连结，而社群活动的内容通常也都会包含搜集回馈、AMA（Ask Me Anything）的桥段。这部分搜集回来的回馈可能会比较模糊、概略，跟我们一般在做针对性的单一使用访谈不同，但是是很好搜集新的使用情境、商业模式可能性的一个场合。
过去产品团队可能是基于某个使用情境开发某个功能，而在这种多人、发散、轻松的场合，大家乱聊之下可能会发现这个功能又延伸出更多不同的使用情境，是能够帮助我们继续进行优化，甚至设计与开发不同产品线的可能性。若行销团队能把这些珍贵的资讯搜集起来给产品团队，也是非常有价值的资讯。
3. 上线与推广策略
这又是一个有趣的“领域专业术语”事件。有一次我被问到“你这个产品的 GTM 策略是什么？”摁…行销的人跟我说 GTM 除了 Google Tag Manager 还会有什么呢？总不会是过气男团 GTM 吧？没想到我又学到了新的一课：Go-To-Market Strategy！
在产品团队内，针对大型功能、新产品会有一套上线规划（Release Plan，商业跟行销团队似乎比较常用 Launch Plan 这个词），从比较产品规划端的这个功能分为几个 Phase；到技术端的每个 Phase 里面有怎么拆分 Tickets、彼此的 Dependencies 为何；以及上线后如何做初步的测试与实验、要订定哪些成公指标来验证。
而行销团队更注重的可能是，当这个产品、功能确定要推后，我们要怎么跟市场沟通？如何让这个好的新功能、新产品出现在现有用户面前，并吸引新的用户加入？
这整个策略包含初期开放给哪些目标用户（TA）、要先 launch 在哪些市场外，也有行销最擅长的处理活动页面、撰写部落格文章、广告宣传、邀请重要用户试用业配等方方面面。
▍与行销团队合作的磨合方向
1. 设立共同关注的指标
在〈共同的目标、不同的指标〉段落中，曾经提到因为关注的指标不同而造成互相影响。而好的产品团队与行销团队，最终的目标就是想办法将共同的目标定义的更明确、将整个使用者旅程的指标都名列下来，包含转换为付费用户、成为流失用户 … 等指标都纳入其中，而不是只关注部分的数据。毕竟行销也有许多手法可以激发僵尸用户、或是帮助 Retarget 流失用户，从产品和行销的角度各个击破才能发挥最大的效益。
2. 建立共同的市场与用户知识库
行销团队和产品团队都会做市场研究与用户研究，因此提供彼此权限来参考对方得到的资讯与内容对整个团队会很有帮助。
3. 让行销团队也拥有一部分的产品 ownership
行销作为需求方处理官方网站、活动页面、SEO 因为主要决策与规划都掌握在行销手上，因此产品团队通常只是被动接收资讯、调配资源，产品经理能够贡献的部分很有限，通常仅限于一些 UIUX 的建议或技术限制，但是这一来一往常常打断产品经理的工作、同时又会吃到前端工程师的资源，因此直接让行销团队作为这些页面的负责人也是一个不错的做法。
通常在行销团队内都会有自己的设计师，那为何不也让行销团队有自己的工程师呢？某些公司会配备拥有 UIUX 设计与研究背景，同时也能够产出前端 code 的角色加入行销团队，通常称为 Web Designer、UIUX Engineer。而这些页面通常也不需要动到产品团队的 QA 资源，因此等于是行销团队自行开需求、规划、设计、开发，只有最后 deployment 的时候需要产品和技术团队一起检查和上线。
▍行销与产品工作的融合，一加一大于二？
基于行销跟产品工作有部份重叠、也会造成一些冲突，一些公司开始思考如何将这两个职能结合，因此出现了一些需要同时具备行销知识和产品管理能力的工作。
产品行销 Product Marketing
产品经理对产品负责，产品行销则是对产品的价值沟通负责。
我曾经短暂担任过 Product Marketing 的职位，当时团队也只有我一个职称有 P 跟 M 两个字的人，因此 PDM（产品经理）、PJM（专案经理）、PMM（产品行销）的工作算是全都包下。如果我的脑袋和内心有个小小的生产线的话，我认为这几个职能稍微可以用时间阶段去分：PDM 负责前期产品规划、PJM 负责中期实作、PMM 负责后期上线后的推广。
整个流程是个循环、而非单向进行。PMM 推广后会蒐集到回馈、会发现某个 TA 推不动而重新定义目标用户和使用情境来推，并以此制定不同的 Landing Pages 并做 Fake Door Testing 来初步确认市场需求、先搜集初步有兴趣的用户名单，再提议给 PDM 脑的自己。（其实满多 PDM 也会做这样的前测就是了～～～）
如果说写 PRD 是产品经理的日常的话，身为 PMM 则会从更源头的 MRD 开始写。在 Gary 《产品经理（PM）与产品行销经理（PMM）的职责有何不同？》中对于 PMM 的工作有更详细的分享，包含定义用户、设定行销活动的评量方式、产品上市规划、对外沟通成功案例 … 等八项，包前包后，比起一般的 PDM，针对市场面、用户面的技能会点的更多，技术面和产品面的能力就不会是重要的技能。
这篇 Intercom 内部团队的文章《What is product marketing? How product marketing builds products》也非常深入的分析产品行销的工作与职责。
成长骇客 Growth Hacker
Josie 在《Growth Hacker 与 一般产品经理有什么不同？》中曾经用一句话形容成长骇客、用户成长产品经理跟功能型产品经理的不同：“相较功能型产品经理拥有产品蓝图与愿景，稳扎稳打铺成整面柏油路；用户成长产品经理，更像是在花园里打造碎片化的石头路。 ”
成长骇客顾名思义就是以成长（Growth）作为最主要目标的一个职能，包含用户的新增、留存、唤回，而要能够达成这个目标，就会需要同时具备产品和行销的知识与技术，尤其数据分析、数据洞察更是必点技能！
更详细的工作内容与差异，就请去参阅 Josie 的文章！她开的线上课程也有用很独到的见解分析传统 Marketer 和现在流行的 Growth Hacker 究竟有什么不同。
至于将行销与产品工作的融合，一加一究竟会不会大于二？就算独立出这个职位了，难免还是会遇到一些难题，例如这个职位应该放在产品团队、行销团队还是独立的专案小组？他的资源是独立的还是与其他团队共用？团队也只能混乱中成长、狂风里拥抱，边跑边尝试了～～～
▍产品经理需要具备行销知识吗？
当然有是最好啊
一来是前面不断提到的，行销跟产品的很多指标是互通的，部分方法论也可以互相参考，再来是对于市场变动的敏锐度、行销工具的理解，例如前阵子发生了《Google搜寻排名改采“行动优先索引”，SEO该怎么因应？》的议题，若产品经理本身就具备对 SEO 一定的了解，就能更快更顺畅的与行销团队合作因应。
我们之前做的《2019 台湾网络业产品经理产业调查报告》在“担任产品经理之前的职能为何”的回答数中，第一名为过去先是担任专案经理，再转到产品经理者、第二多一开始就为产品经理者，第三名就是行销再转职为产品经理。相信很多技能与思维是互通的。
若有兴趣更深入了解产品与行销、数据的结合，Women in Data Science Taipei 也将在三月底举办 2020 WiDS Taipei Conference，主题聚焦在目前很热门的“行销科技（Martech）”分享业界第一线数据驱动行销 Data-driven Marketing 的经验与见解。