在创业公司,老板和基层员工都必须懂财务

在创业公司,老板和基层员工都必须懂财务

如果你在创业公司工作,应该知道自己的职责可能比开始时职位描述的范围大。这是一件好事,意味着你会拥有更好的学习机会,可以在角色之外学习:创业公司的员工应该稍微了解一下企业是怎样运营的。

我在High Alpha工作,这是一个风险工作室(venture studio),我为企业提供财务服务,直到它们做好准备,招募一名全职财务主管。曾经有同事问我,每天的工作是不是盯着数字,我的许多工作的确与电子表格有关,不过高级策略显然更有趣。创业公司的财务工作似乎很神秘,为了让它不再神秘,我将它划分为四大内容,这些内容创业公司的每一位员工都应该了解一下。

1、预算和预测

——为什么你应该及时上交费用报告?

在创业公司内,眨眼之间计划就会改变;尽管如此,企业仍然需要一套高级路线图,将它纳入到财务规划中。预测(许多时候就是Excel文档)告诉我们每月的销售目标(这个月比上个月增长多少)、招聘计划及其它费用是怎样的。根据规划,可以预测企业何时耗光现金(假定企业还没有盈利),什么时候需要融资。

财务团队应该帮助企业找到平衡,一面是很高但是可以达到的销售目标,另一面是预算成本,确保企业拥有必要资源,但是现金的消耗速度不会太快,财务团队帮助企业在这两点之间找到平衡。与计划相比,企业的进展如何,团队应该不断评估。如何做到呢?至少每个月都要收集实际费用数据,确保公司与计划相符,在公司陷入麻烦之前先找出任何不同的地方。正因如此,及时提交费用报告相当重要:当前花了多少钱?只有掌握足够多的信息,企业才能给未来制定决策。

作为一名创业公司员工,你要让现金流进来流出去。团队的每个人都会为销售做贡献,有的是直接销售,有人扮演营销角色,还有一些人间接做贡献,比如开发产品(开发最好的产品让销售更容易)。如何快速花钱?似乎每个人都有绝妙的想法。因为创业公司没有无限的现金流,如果你有一个想法,花的钱不在预算之内,那就像财务主管一样看待它:这些现金投资能带来销售并弥补成本吗?或者说花这些钱值得,因为可以融到更多资金?第二点很难判断,不过有一点你要知道,公司向外部投资者融入的资金越多,员工股权就会稀释得越厉害;如果你拥有员工股权期权,意味着它的价值会降低,关于这个问题后面我会多说几句。

2、KPIs(关键绩效指标)

一些创业公司将某些数据、指标纳入工作报告,财务团队会追踪、分析数据。通过观察分析数据和趋势,我们可以将分析结果报告给公司领导者,帮助他们做决定。

行业不同,企业所处的阶段不同,KPIs也不同,不过有一些指标是所有创业公司通用的。

——现金

一个指标是现金。知道公司焚烧现金的速度有多快,知道每个月银行帐户的现金减少了多少,这些信息很重要:对于创业公司来说,现金耗光是最糟糕的事。评估现金效率也很重要,所谓现金效率,就是每花掉一美元得到多少美元的营收。评估现金效率可以帮助我们了解趋势。作为一名员工,你可能不知道总现金是多少,也不知道每月花了多少钱,不过你应该知道公司领导最关心的就是这些数字。

——营收和增长

KPIs还有一个很重要的部分,那就是营收和增长。如果创业公司得到了VC的支持,它会高度重视营收增速。在SaaS和付费订阅世界,年或者月循环营收(ARR或者MRR)是一个重要指标。

——客户满意度

团队应该关注客户满意度。在SaaS行业,我们会观察客户变动率,这样就可以根据客户的逗留时间判断他们的终生价值。

投资者会关注这些KPIs。他们会将公司的现金效率、营收增长率、客户变动率与行业其它企业对比,决定是否投资。正是出于这个原因,领导者知道理想基准是什么才会变得很重要,财务团队应该帮助公司设定目标,制定强有力的财务计划,达到基准。

3、融资

有些VC支持的创业公司非常成功,它们具备这样的特点:公司启动时会有一些资金,建立一支出色的团队,还可能会“购买”一些客户。然后又会融入一些资金,走到某个“里程碑”(销售里程碑或者产品里程碑,或者同时达到)。接下来企业不断融资,不断达到里程碑,直到公司盈利,以某种方式退出(比如收购、IPO)。

作为一名创业公司的员工,你可能不会直接参与融资,但是知道融资的基本流程对你有利,可以让你理解公司的愿景,对公司的现金支出有更好的了解,因为融资非常难。当公司需要现金时,企业要提前6个月融资。寻找适合的投资者、向他们推销是需要时间的,而且很费力。一旦投资者有兴趣,他们会展开尽职调查,如果是处在晚期阶段的企业,投资者的调查会更严格,它会查看公司的各项指标、财务数据。然后还有法务方面的事情,需要确定融资条款和估值。

创始人按这样的方法出售企业的一部分,他们会尽量少出售一点股份,卖出更高的价格。正因如此,尽可能融入更多资金并不一定是明智的:当然,有了更多的资金企业可以跑得更远,但是抛售的股份也会更多。这就是所谓的“稀释”,如果你握有员工股权,就会受到直接的影响。

4、股权和员工期权

创业公司一般会给员工一些股权,这样做相当于支付部分薪酬,不必提前花费现金,而且还能激励员工。当企业运营很好,达到目标,企业的价值就会上升,员工股票的价值也会水涨船高。

理解员工期权和股权是怎么一回事相当重要。你应该知道与期权协议、行权计划和行使价格有关的条款是怎样的。有许多文章解释这方面的问题,你可以读一读。我只想告诉你为什么应该关心。

握有股权期权,意味着你有机会拥有公司股票。公司值多少钱决定你的股票值多少钱,每一次公司融资,价值都会变化。达到目标,拥有充足的现金,就能获得更好的KPIs,进而抬高估值。

因为公司没有上市,你不能随意出售股份。如果公司成功了,你的股票就能流动起来,也就是说你可以将股票变成现金。当你的公司被收购或者上市时,就可以变现了。如果估值很高,股票就会更值钱,获得的回报也会更大。

在创业公司内,每一位员工都是决策制定者,都对公司的成功至关重要。你是“建造”团队的成员之一:开发产品、构建文化、打造业务。在这种环境下,除了自身扮演的角色,你还可以了解其它角色,对整个业务有更好的理解。要不断提问,即使问的事情与你的角色没有直接关系。你对大局的理解越清晰,越能发挥价值,帮助公司走向成功。

原文链接:https://medium.com/high-alpha/what-every-startup-employee-should-know-about-finance-98487c64e3bb

成为产品负责人的第一年里学到的6件事

一年前的今天,我从Sainsbury的数字企业事务部转到了Sainsbury的数字和技术部门,开始了我作为一个产品负责人的新生活。

我一直认为自己是一个对网络和数字有着极大热情的极客,所以我特别兴奋能够机会来尝试这个新挑战(一年后,我还是如此!)。

为了庆祝我成为产品负责人的一周年,我认为我应该把我遇到过的经验教训写下来。

1.提问而不是说“No”

0btvyr-rolts4g0l-2

产品的想法和功能需求会来自四面八方。作为一个新的产品负责人,我的第一反应是对所有事情说“Yes”。虽然短期内人们很开心,我却很快挤压了一大堆待办事物,并且没办法将它们全部交付出去。

不立马回复“Yes”,取而代之的做法是提问。这帮助我更多地理解这个需求。我能够更深地了解,为什么他们认为这对于我的产品来说是个好主意。他们认为会实现什么?他们设想它如何工作?他们期待实现什么?你得到了答案。

如果一个想法通过了这些积极的挑战,它最终对于我的产品是有用并且有价值的。作为对话的一部分,我也学会了制作一个带有验收标准的用户故事的开始。同样,环境和推理有助于我评估,这些新功能如何与现有的功能比较,以及如何确定优先等级。

2.你不知道什么是你不知道的

3

我知道这很奇怪,然而我们正在讨论的问题,作为一个新的产品负责人,我仅仅只听过理论上的Scrum, Agile, Sprints, Jira, Slack——有一些问题,我根本不知道要问!

你唯一知道要去问的是一旦你启动了一个产品,一旦你已经经过了几轮测试,应该如何去建立一个路线图,如何去跑一个产品demo。和任何其他工作一样,理论旁的经验是关键,并且只能依靠时间的积累。

我非常幸运的加入了一个经验如此丰富的Product Owner团队,他们帮助我沿着这段经历,把正确的人员和流程介绍给我。因此,在我第一年发布了我的第一个产品,和整个部门的同事大量互动之后,我感到更加的自信。

3.打破产品

我的老板有一套非常有用的小技巧,他总能有效地拆分我的产品。这个你是怎么考虑的?如果这发生了怎么办?你的依赖是什么?你的B计划是什么?这个过程非常有用,而且这已经变成了我的一串咒语。在进入更广阔的受众群体前,先在一个安全的环境里将产品打破。

我想起了我在企业事务部时的日子,那里有一些有益却玩世不恭的话:把好故事和无聊的故事区分开,并总为最坏的事情做好准备。

就好像制作一个强大Q&A文档以便我们碰到狡猾的媒体问题,这样做的目的是为了你的产品达到这样的程度——所有的东西都能很好的融合在一起,有着很棒的体验,并满足了业务目标。

4.沟通,沟通,沟通

1

我实在是无法领会,作为一个产品负责人需要花费多少时间在交流上。和我的scrum 团队开优化会议,和其他的产品负责人碰撞路线图,和建筑师讨论具体细节,理解利益相关人实际想要是什么,客户……有机会的话,你应该停止看这些话,立即和他们交流。

作为一个产品负责人,我应该为我的产品负责。我得做决定——但是只有我和产品中每个人在一起,每个人都理解了产品是什么,它计划实现什么的时候才能做决定。如果人们不理解为什么我要做这个决定,他们可能不会赞同这项决定。

5.好多的会议

要和这么多人沟通交流,要在像Sainsbury如此大的组织里工作,意味着我有大量的会议,根本没有时间做什么实际工作。

我到现在都没有解决这件棘手的事情。我尽量确保Agile仪式提前预定好,同样确保我有大量的时间可以用来工作。

6.纸

在做产品负责人这一年中,我花在草图和图画上的时间,比五年里在企业事务部团队时全部加起来的还要多。这个简单的事实很讽刺,为了用敏捷方式构建一个数字产品,你最终会用掉大量的纸。

何谓优秀的产品团队?

我的朋友和同事,Jeff Patton,即将出版一本关于用户故事尤其是故事地图技巧的书。我被邀请作了此书的前言,这篇文章就摘录自前言。我同样是这本书的书评,这本书真的是一本产品人的必读书,而且填补了当前图书馆中关于“敏捷”这个话题的空缺。

我曾和世界上最好的科技产品团队工作,他们创造了你今天正使用以及喜欢的产品,他们也确实在改变世界。

我同样曾试着去帮助这些做得不是太好的公司。初创团队在资金用完前争相追赶,大公司则挣扎于复制早期的创新。团队没法持续给他们的业务增加价值,领导人则因想法转换为现实所花的时间太长而烦恼。开发人员老是惹怒他们的产品拥有者。

我所学到的是,最好的产品公司在如何创造科技产品方面和其他公司存在巨大的差异。我指的这个差异不是一点点。从领导人的行动,到团队授权,到组织思考如何提供资金,如何招募团队,以及如何生产产品,小到产品、设计、开发如何协作去探索为客户提供更有效的解决方法,每一件事都不同。

对于这些没有机会参加,或者近距离观察一个优秀产品团队的产品经理,在这篇文章中,你将得以一瞥优秀的产品团队和糟糕的产品团队之间的差别:

·好的产品团队有一个宏大的产品愿景,并带着一种使命感般的热情,糟糕的产品团队则唯利是图。

·好的产品团队从KPI考核、关注用户痛点、分析客户使用产品所产生的数据、持续探索应用新技术来解决实际问题中得到灵感和产品想法,糟糕的产品团队从销售和客户手中收集需求。

·好的产品团队了解他们的每个关键利益相关者是谁,他们理解这些利益相关者的约束,他们提供的解决方法不仅对用户和客户有用,同样也在业务的限制之内。糟糕的产品团队只会从利益相关者手中收集需求。

·好的产品团队用大量的方法来广泛尝试产品想法,然后决定哪种是真正值得投入,糟糕的产品团队通过会议来产生优先级路线图。

·好的产品团队喜欢和整个公司里聪明的有思想的领导人一起开头脑风暴讨论,差的产品团队一有团队外的人给他们建议做某件事时就会很恼怒。

·好的团队,产品、设计、开发人员是坐在一起的,就功能、用户体验与可用性技术之间的充分交换意见。糟糕的产品团队坐在他们令人尊敬的功能区,要求其他们人安排会议或者文档为他们提供服务。

·为了革新,好的团队会持续尝试新方法,但是是以保护收入和保护品牌的方式,糟糕的产品团队仍然在等待许可做一个测试。

·好的产品团队坚持认为他们必须具备创造获胜产品的技能,例如强大的交互设计。糟糕的团队甚至不知道交互设计师是什么。

·好的产品团队确保他们的工程师每天有足够的时间用于实现产品原型探索,以便于他们能致力于如何将产品变得更好。糟糕的产品团队在sprint计划阶段给工程师展示原型,以便于他们能够作出评估。

·好的团队每天都和终端用户以及客户直接联系,去更好的了解他们的客户,去看他们的客户对于他们最新想法的反应。糟糕的产品团队认为他们就是客户。

·好的产品团队知道,他们所喜欢的大部分想法中有许多最终并不会为客户工作,即便能实现的那一个也需要反复迭代,才能够实现他们想要提供的结果。糟糕的产品团队只会按照产品路线图进行,并满足于会议数据和质量保证。

·好的产品团队明白速度以及如何快速迭代是革新的关键,他们也明白这种速度来源于正确的技术而不是强制劳动。糟糕的团队抱怨因为同事没有努力工作而速度太慢。

·好的产品团队会在他们评估完需求,确保他们有一个可视化的能够实际为客户和业务有用的解决方案后作出重诚信的承诺。糟糕的产品团队在痛苦的整合结束后进行手动测试,然后立刻发行所有产品。

·好的团队痴迷于目标用户,糟糕的团队痴迷于竞争对手。

·好的团队会为他们对业务KPI产生重大影响时庆祝,糟糕的团队会在他们最终发布了某些东西时庆祝。

如果以上这些你的团队不幸中了大多数,我希望你会考虑为你们的团队提高要求,并且看看是否你能体会到这些差异。

优秀PM必备的三大技能:如何发展一个强大的产品团队?

在我的上一篇文章中,我讨论了产品管理领导者的角色后,收到许多产品领导人的来信,他们在信中说,他们在构建产品团队力量这一块做得不是很好,想要我分享一些方法来解决这个问题。

每个产品领导者都需意识到这个问题的紧急性和重要性。你的公司需要最强大的产品团队,但如果你不去发展你的团队并为之提供成长机会,那其他公司会。我一直相信一句老话:“员工因公司而加入,却因管理者而离开。”

这篇文章讲述了我使用并提倡,为持续技能评估和发展提供了一个框架的方法。我把这称之为发展计划,但对有的公司而言,这种发展计划只发生在遇到问题必须提升员工的时候。然而这些方法同样适用于在持续的基础上,培养一名强大的产品所有者(product owner)或每个员工。

这些技能评估发展计划是基于差距分析模型架构出来的。主要是为了确认发展方向,并参照这个准则了解目前自身处于哪个水平。例如,这一系列的标准都有两个等级。第一个等级是员工应该达到的高度的一个评估(例如它的重要性),第二个标准是员工当前水平的一个评估(例如,他的能力)。

不是所有的技能都是同样重要的,也不是所有的差距都具有同样的意义,这套机制是为了帮助我们找准需要专注的地方。

技能评估

我将这套标准分为:知识、过程技能以及个人技能三类。每一点都有一个简短的描述,如果你对这些有什么不清楚的,可以在博客SVIP中找到每一条对应的文章。

这其中包含了我个人对一个中级产所有者的能力要求。然而,我鼓励每一个管理者根据你们独特的文化,行业,团队,以及产品,同样还有位置的等级(例如高级产品拥有者的级别高于副级产品拥有者)调整能力要求。

在这个等级评定中,0代表不重要(或不是很强),10代表非常重要(或很强)。

知识:

  • 用户/客户知识(10)——公司承认产品拥有者是目标用户/客户方面的专家吗?
  • 行业/领域知识(10)——产品拥有者的行业/领域知识怎么样?
  • 产品知识(10)——产品拥有者的产品知识是什么层级?
  • 技术知识(8)——基础的技术知识了解得怎么样?他目前的技术知识怎么样?
  • 用户体验设计知识(7)——产品拥有者对于用户体验设计的知识怎么样?他了解UX的各种表现,能够辨认并用之于团队吗?
  • 业务以及金融知识(7)——产品拥有者了解经济学及产品的金融动态吗?

过程技能

  • 客户探索过程(7)——客户探索包括客户面试技能、机会评估以及客户的开发计划的理解。
  • 产品探索过程(9)——这是为了获得最低可行产品。这包括定性技术:用户原型以及用户测试,同样包含定量技术:实时数据库原型以及分离测试。
  • 产品优化过程(9)——这些是快速改进和完善现有产品的技能,特别是用优化技术或者A/B测试。
  • 产品发展过程(7)——产品所有者是否对产品开发过程(如:Scrum开发)有深入理解,理解他在创建以及管理积压任务中的关键作用?

个人技能

  • 团队协作技能(10)——产品所有者如何主要头开发者和首席设计师有效工作?它是一个协作的关系?有相互的尊重?产品拥有者和主要开发者以及首席设计师的合作够早吗?是否给他们提供了客户的直接访问方式?
  • 产品传道技能(9)——产品所有者能否有效分享产品的愿景并激励整个产品团队、相关的利益者以及公司中的其他人对产品做出必要贡献?
  • 时间管理技能(8)——产品所有者如何管理他的时间?他能确保有足够的时间来解决关键性问题吗?还是大部分时间花在日常消耗上?他是否充分利用了他的项目管理者或者ScrumMaster?
  • 利益相关者管理(7)——产品所有者管理利益相关者的能力怎么样?这些利益相关者是否感觉到他们真的拥有一个能够帮助他们取得事业的成功的真正的产品伙伴?
  • 领导技能(6)——产品拥有者实际并不管理任何人,但是他们确实需要领导、影响以及激励别人,所以领导技能是很重要的。
  • 社区管理(5)——产品拥有者在社区管理上和温和部署技术方面的技能怎么样?
  • 广阔的产品视野(5)——产品拥有者是否努力维持一个广阔的产品视野,并确保端对端强大的用户体验?

一旦你确定了这些标准的能力要求,你就能够评估每个产品所有者在这些标准中的位置,从而找出其差距。

发展计划

技能评估只是第一部分,第二部分是找出最大差距的领域,然后由管理者制定一系列的计划,让产品所有者去提升这些领域的技能。如果某项技能,如“产品探索过程”在重要性中是9分,但他当前的技能水平只达到了5分,一个如此重要的技能却存在如此大的差距。作为管理者,你现在现在就为这位产品所有者制定训练、阅读计划或者锻炼来提高他们在产品探索方面的技能。

对于发展计划,首先只集中在最要紧的三个领域。等这三个领域的技能都提高之后,员工才可以移到下一个重要的领域。

如果员工成功的缩小了这些差距,是时候让他们展示这个提升的过程,并且他们可以将必要技能的展示用于晋升。

确保至少和每个产品所有者每月都有一次发展计划进程以及技能水平调整的讨论,尤其强大的管理者可以一周讨论一次。

最后,你可能想知道这种技能评估和发展计划如何与年度绩效考核相关。通常而言,大部分的公司做绩效考核候,很少考虑到“发展一个强大的产品团队”这点,他们更关心合规和薪酬管理。

你也许不得不顺从人力资源部门对年度考核的要求,但必须意识到,这并不能充分替代每个团队中成员在积极、持续、有计划的发展。如果你正积极制定我所描述的技能评估以及发展计划,那么年度考核是相当容易的。

原文地址:http://svpg.com/developing-strong-product-managers/,由xia tian翻译整理发布于YiboDesign。

产品失败的十大根本原因,任何一条都足以摧毁一个团队!

在这篇文章中我想去讨论许多产品失败的根本原因。

我看到在绝大部分公司用的都是相同的基本工作方法,我不禁想提醒这和那些好公司的实际工作方法相去甚远。

我不得不提醒你这讨论出的结论可能会非常令人沮丧,甚至有点太打击人,如果是这样的情况,我觉得你可以停在这里不必往下看了。

让我们从绝大多数公司仍在用之创造产品的过程开始,我会试着不发表评论,我们仅是描述这个过程:

任何事情都始于想法。在大部分公司,想法来源于执行董事,或者关键的利益相关者,或者企业主,或者大客户(或潜在客户),但是任何情况下业务的不同部分都有一大堆事情需要去做。

现在大部分公司想要在路线图中确定这些想法的优先顺序,他们这样做基于两个理由。首先,他们想要我们优先专注于最有价值的事情,其次,他们能预测事情何时能准备好。

为了做到这一点,通常会有某种形式的季度或者年度计划会议,会上领导就这些想法思考并协商出一个产品路线图。但是为了确定优先顺序,他们首先需要为每个项目提供某种形式的商业案例。

一些公司会形成正式的商业案例,一些则是非正式的,但不管是哪一种,归根到底,关于每个想法都需要了解两点:1)它将赚多少钱?2)它将花费多少时间或金钱?然后用这些信息来提出下一个季度有时也可能是一年后的产品路线图。

在这一点上,产品和技术部门有他们自己的工作节奏,通常是按照项目的优先顺序,从最高优先级依次往下走。

一旦一个想法被确定为最高优先级,产品经理需要做的第一件事就是和项目利益干系人讨论,将想法具体充实化,并提出一系列的“需求”。这有可能是用户故事,也有可能是某种形式的功能细则,但目的都是为了和设计师以及工程师沟通需要创建的是什么。

一旦需求被收集起来,用户体验设计团队(假设公司有这样一个团队),就需要提供交互设计,视觉设计,以及物理设备情况下的工业设计。

最后将需求以及设计细则交给工程师,这时敏捷开发最终登场。

无论如何,工程师通常会将项目划分成一系列的迭代——在敏捷开发模型中这称之为“sprints”。想法构建出来可能需要1-3次敏捷迭代。

很希望QA测试是这些敏捷迭代过程中的一部分,如果不是,QA团队应该用其他的测试跟进,确保新产品和宣传的一致,同时不会引进其他问题(称之为“回归”)。

一旦我们在QA团队那拿到了绿灯,新想法可以最终部署给真实客户了。

在我第一次见面的绝大多数公司,无论大小,重要的是他们的工作方式,并保持这样的方式工作了很多年。但也同样是这些公司,他们不断抱怨着缺乏创新,从想法到落地需要非常长的时间。

你也许已经意识到,当我提及敏捷开发的同时,几乎今天的每个人都宣称是敏捷开发,而我刚刚描述其实更多的是瀑布过程。公平说来,对于工程师,如果他们能够给更广阔的瀑布环境,他们能做的其实和敏捷开发一样多。

1

OK,既然大部分团队都是敏捷开发,但为什么那是如此多问题的必要理由呢?

我现在想做的就是将这些点连接起来,向你展示为什么这种普通的工作方式要实际为大部分失败的产品努力负责。

关于这个问题我可以畅谈一整天,但我即将分享的是我认为这种工作方式中,最严重的10条问题。更清楚一点,我所讲的这十条都是非常严重的问题,其中任何一条都足以摧毁一个团队,但大部分公司占了这十条中的大多数,甚至,全中。

1.让我们从最上面那条开始——想法的来源。这种模式导致了销售驱动特价,以及利益干系人驱动产品。想法的来源有很多,但是这不是我们产品想法的最佳来源。这种方式的另一个结果是团队缺乏自主权——在这种模式中,他们只是在那儿执行,就像一个雇佣兵。

2.接下来我们谈一谈这种商务案例中的致命缺点。我实际是支持做商务案例的,至少对于想法需要一个更大的投资。但与此同时,大部分公司在这阶段做商务案例,为了想出一个确定了优先顺序的产品路线图,确实是可笑的。为什么?还记得每个商务案例中两项关键的投入是什么吗?你会赚多少钱?它又会花费多少?冰冷的现实是,在这一阶段,两者我们都不会有答案,我们不可能知道。

我们不可能知道我们会赚多少钱,因为这很大程度上取决于我们的解决方法会变得有多好。如果团队表现杰出,这可能会取得巨大的成功,的确有可能会改变公司的进程。另一方面,许多的产品想法会落得一场空。这并不是夸大其词。确实是什么都没有。任何情况下,产品中最重要的一课是明白”什么是我们不可能知道的”,在这个阶段我们不可能知道的是,我们能赚多少。

同样地,我们也不可能知道构建出这个想法需要花费多少。在不知道实际解决方法的情况下,工程师是很难去预测的。在这个阶段,大部分有经验的工程师甚至会拒绝去给出一个估算,但有些工程师迫于压力,只好作出老式“T恤size”式的妥协——仅仅让我们知道这预算是“小的、中等的、大的还是特大的”。

但公司高层确实想得出确定了优先顺序的产品路线图,为了得到它,他们需要某种系统来评估想法,所以人们就玩起了商务案例的游戏。

3.一个更大的问题来了。公司对他们的产品路线图感到十分兴奋。我见过数不清的路线图,绝大多数确实按照特征确定了优先顺序。市场需要这些特征来搞商务活动,销售需要这些特征来招徕新客户。一些人则想要一个PayPal集合。你懂的。

但是这里有一个问题,也许是其中最大的问题,我把这称之为“不愿面对的两个产品真相”。

第一个真相是,我们的想法至少有一半是不能实现的。一个想法不能被实现有许多理由。最普遍的是,客户不会如我们一样对想法感到兴奋。所以他们不会选择去使用它。有时他们想去使用它,但是他们试过之后发现它是如此的复杂,麻烦远大于它的价值,所以导致了同样的结果——用户不会选择去使用它。有时问题是客户很喜欢它,但要实现的东西远超出我们的想象,我们并没有足够的时间和金钱来实际实现。

所以我向你保证,你的路线图中至少有一半不会如你所愿实现。同时,真正好的产品团队认为,至少有四分之三的想法的表现都会不尽人意。

如果这还不够糟,第二个不愿面对的真相是,尽管这个想法被证明有潜力,它通常需要经过几次迭代之后才能实现它的想法切实传递商业价值。我们称之为 “时间就是金钱”。

我所学习到的关于产品最重要的一点是,无论你有多聪明,都逃不过这些真相。我曾有幸和许多杰出的产品团队工作。真正的差别在于你如何处理这些真相。

4.接下来我们要谈论的是这种模式下的产品角色。事实上,我们根本不用把这个角色称之为产品。它实际上只是一种项目管理的形式。在这种模式下,它更多的是收集需求并为工程师们记录下来。在这一点上,我们可以说,它离现代产品管理差了180度。

5.关于设计的角色也是同样的故事。设计发挥真正的价值已经太迟了,他们所做的大部分工作,我们称之为“给猪涂唇膏”。破坏已经造成,现在我们只是尽力去给这堆乱七八糟的东西画上一件外衣而已。UX设计师知道这并不好,但他们还是尽可能地让它看起来好,看起来一致。

6.在这种模式错过的最大机会也许是工程师用这种方式完成得太晚。我们说如果你只是用你的工程师码代码,你只是得到了他们一半的价值。产品里有个小秘密是,工程师其实创新最好的单一来源,但他们甚至都没有被邀请参加这个过程的party。

7.不仅是工程师带进这种方式太迟了,敏捷开发的原则以及核心利益进入得更迟。团队也许只发挥了敏捷方式真正价值以及潜在价值的20%。你真正看到的是敏捷用于交付,但是剩下的组织以及环境根本不敏捷。

8.这整个过程是非常以项目为中心的。公司通常会为项目提供资金,人员并通过组织推动这些项目,最终启动项目。不幸的是,项目只是产出(output),而产品则是全部的结果(outcome)。这个过程预见性的导致了孤立的项目。是,某个东西最终会发布,但它没有达到它的目标,所以真正的那个要点是什么?在任何情况下,这都是一个严重的问题,它并没有达到我们需要构建的产品预期。

9.老的瀑布流进程一直以来,并且还会持续的一个最大缺点是,所有的风险都在最后。这意味着客户验证太晚了。

你也许听过精益生产法,这是大部分人的选择。关键原则在于减少浪费,而最大的浪费形式之一是设计、建筑、测试以及配置功能或者我们并不需要的产品。讽刺的是许多团队认为他们正在使用精益法,但是他们进程的跟进就如我刚刚所描述的。然后我向他们指出来,他们实际正尝试的是我们现在所知道的最昂贵、最慢的方法之一。

10.最后,我们忙于这个过程的同时也是在浪费时间和金钱,结果最大的损失在于机会成本,组织原本能(could)拥有的机会现在却只是应该(should)拥有。时间和金钱一去不复返。

对于我来说,大量的公司花费大量的时间和金钱却收效甚微,这并不奇怪。我警告过你,这可能是非常令人沮丧的。

好消息是我保证最好的团队从来没有发生过如我刚刚描述的事情。

关于最好团队是如何工作的,我从不同的方面写过许多文章。产品探索是指我们如何用成功的方法解决我们正在面临的问题。探索是一种产品、用户体验设计以及工程开发之间积极的、不间断的合作。持续的探索与持续的交付并行。路线图(output)上的特征被解决业务问题(outcome)所代替。目标是产品/市场契合。

如果你的公司还在用这种老的早就被淘汰了的过程,我希望你能发光,开始向未来过渡。并希望你在做之前发现,你已经被比你更快更具有效率的初创团队或者竞争对手所打破。

一名优秀产品设计师,该做好的5项工作

产品设计师的角色

你要招一些内部设计师,那真是一个好消息!直到现在为止,你大部分的设计工作都依赖于一个外部代理,招一些内部设计师将有助于你组建一个更有效、更可预测的团队。

你的下一个任务是定义公司里产品设计这个角色。这是一个非常重要的角色。你不想只是简单地重现一个代理模型的内部版本。近年来,产品被创造的方式已经发生了重大变化,对于设计来说,新模式是其中至关重要的一部分。

下面将讲述现代产品设计师这个角色所做出的一些重大贡献:

产品定位

在老的模式中,设计师从产品经理那拿到需求或者详细规范来进行他们的设计。现代产品设计师则是不断的和产品经理以及工程师们协作。不仅限于最近项目的“设计阶段”,现代设计师应该参与一个产品从开发到上线到迭代的所有阶段。现代设计师应该和他/她的产品经理,如果有可能的话,和开发这个产品的所有工程师们坐在一起,而不是和年轻的设计师坐在一起。不是用设计工作产量来衡量一个产品设计师,而是用他们产品的成功来衡量。

timg-2

提到这些,好的产品设计师就会有许多和产品经理一样的需要担心的事情。他们深切以真实客户为导向,并且他们产品的价值就是带给这些客户的。他们同样明白,产品是为一个行业服务,并且将这些担心以及约束涵盖进一个产品设计里。设计师应该更进一步理解,对于用户价值来说,用户体验和基本功能同样重要的。

整体体验设计

用户体验(UX)比用户界面更重要。一些人甚至使用术语“客户体验(Customer Experience)”来进一步强调这一点。UX是客户以及终端用户识别你产品价值的某种方式。对于现代产品,它包括随着时间的推移客户对你公司以及产品的全部接触点以及交互方式。对于现代产品,这通常包含了多重不同的UI设计(网页,移动端,桌面等等),也包含了其他的客户触点(邮件,客户支持,通知,在线存储组合等等)。对于一些产品,UX同样包含了线下服务,如乘坐通过Uber召唤的车,或者住在通过AirBnb提供的房子里。

timg

好的产品设计师工作时需要带着一个广阔的UX视野。他们把客户在某一段时间内对产品以及公司的交互作为一个整体。根据产品,触点的列表可能会非常长。好的产品设计师应该考虑像这样的问题:

1、客户首次如何了解这个产品?

2、新用户如何登陆,以及如何(也许是逐渐的)发现新功能?

3、用户在一天中的不同时间段可能会如何产生交互?

4、还有什么其他东西在抢夺用户注意力?

5、一个一个月的老用户和一个一年的老用户有什么不同?

6、我们如何激发一个用户对于这个产品更高水平的承诺?

7、我们如何创造满足时刻?

8、一个用户会如何将他们的体验分享给其他人?

9、解决一个支持问题可能会是什么样?

10、客户如何接收一个线下服务?

11、什么是产品的感知响应性?

原型

现代产品团度最重要的工具之一是原型。探索出用户热爱的产品需要持续和同事协作以及不断和客户以及终端用户确认。原型提供了促进沟通的工具。比起线框图或者截屏,原型是一种更精准的想法呈现,因为他们能够抓取完整用户体验的许多其他方面。

timg-3

过去画原型需要工程师,但是随着原型工具的质量的提高,已经不再需要工程师。也有一些例外,但是现在主要的原型已经不需要工程师了。反而是设计师来画原型,他们能够用来画原型的工具已经戏剧性的提升了。好的产品设计师使用原型作为他们内外部交流思想的主要画布。他们游刃于大量不同的原型工具之中,依据手边的工作使用不同的工具。

用户测试

好的产品设计师会基于真实的用户和客户持续测试他们的想法。他们不仅在一个产品或概念成型的时候测试,而是会将测试纳入他们的周计划里。这种固定的节奏意味着他们能够不断确认、完善想法,同时能够收集一些他们之前也许并没有找到的新方式。这也意味着在他们接触外部客观意见之前,他们不可能过于依赖想法。

用户测试比可用性测试更加宽广。产品设计师以及他们的产品团队利用可用性测试来评估他们想法的价值。客户会实际使用或者购买产品吗?如果不会,它还需要什么?

交互和视觉设计

视觉设计和交互设计曾被当成两个独立的角色。视觉设计包括像布局、字体以及视觉品牌如何会表达类的东西。交互设计通常包括像基础的概念模型(例如一款照片管理应用也许有“照片”、“专辑”、“项目”等等),任务流以及控制图层来管理这些概念。

sleeping_beauty

现代产品设计师也许有不同的特长,但是一般来说都包括视觉以及交互设计的技能。拥有更多具有竞争力的技能,允许他们根据上下环境快速制出不同等级的保真度。它还允许他们单独考虑交互和设计时,能以不可能的方式下设计经验。这在移动端界面中特别重要,当设计师必须要创造一些新的和视觉设计互相交错的交互模型时。

所以现在怎样?

你说,这一切都很好,但这些人很难招到。招到牛叉的人是非常困难的工作,但就像我们需要招聘一个强大的产品经理和强大的工程师一样,招到一个强大的产品设计师也非常重要。

你想尽可能快的为你们组织找到一个强大的设计师,但是强大UX的责任不应该仅仅来自于他们。它同样涉及到产品团队中的其他成员,像产品经理和工程师。你可以立刻提高“对于强大的UX是什么”的意识以及设置对其的期待。确保你的工程师以及产品经理明白产品在用户体验中的价值有多高。鼓励他们在用户了解这个产品之前就开始广泛的思考一个完整的用户体验。让他们用原型以及用户测试去证实他们的想法。

现代产品设计不仅是招聘员工,它将为你的团队和你的进程找到设计重点。

原文地址:http://svpg.com/the-product-designer-role/,由Summer翻译整理发布。

eBay前副总裁:每一个伟大的产品背后

 

这篇文章主要讲了这20年来几款伟大的产品及其背后的产品经理运筹帷幄的故事:90年代的微软的 Word for Mac、90年代末出租 DVD 的 Netflix、2000年的Google Adwords、08年的 iTunes 等。文章很长,需耐心读完。

当我刚开始决定创建The Silicon Valley Product Group(硅谷产品集团)时,我刚离开eBay,对于什么创造了伟大的产品团队以及伟大的产品文化有一些非常强烈的想法,尽管已经有一些重要的思想家和领导人讲过这个话题,但我认为产品管理这个角色还没讲得不够。所以当时我做的第一件事,就是坐下来写了一篇我对于这个角色理解。这篇文章的标题,“Behind Every Great Product”灵感来源于Ben Horowitz的经典文章《Good Product Manager / Bad Product Manager》。这篇文章被证明是受欢迎的,并帮助很多团队对于产品到底是什么有了一个更好的理解。

现在,十多年过去了,我想重温这个主题,于此有三点主要的原因:

  • 首先,尽管我个人花了很多自己的时间在产品管理的写作、指导以及教学上,但对于这个角色仍然有一些相当混乱的小问题。这有很多原因,但仅仅是因为它太重要而没能继续。
  • 其次,自从我第一次写完这篇文章后以来,我又学到了更多。我有机会和来自众多领先技术公司的了不起的团队以及产品经理共事,这帮助我对于这个角色,以及成功的必要因素有了一个更好的理解。
  • 第三,我认为这个角色比过去更加重要,我将这个角色作为成功的关键因素,失败与成功之间的差别常常就在此。

我始终相信在每个伟大的产品背后,通常有某个在幕后不屈不挠工作的的人扮演了这个至关重要的角色。他们通常有一个叫“产品经理”的tittle,但他们也可能是一个初创公司的联合创始人或者CEO,或者他们也许是团队里另一个角色,因为他们看到了这个需求后承担了“产品经理”的职责a。tittle不重要,重要的是他们的工作。

基本上,产品经理有三种工作方式,我认为它们之中只有一种能走向成功:

  • 他们把每一个问题和决定上报给CEO。在这种模式里,产品经理只是一个待办事项管理员(backlog administrator)。很多的CEO高告诉我他们就是这种模式,而且并没有什么用。如果你认为产品经理的工作就像CSPO(Certified Scrum Product Owner 产品负责人认证)课程里描述的那样,你也会掉进这种模式里。
  • 他们会把所有的项目干系人召集进一个房间,组织一个会议,然后让他们解决——这就是所谓的由委员会决定,然而这种模式除了平庸什么也产生不了。这在许多大的公司非常普遍,在这种模式中,产品经理通常是一个项目负责人或者蓝图管理者(roadmap administrator)。
  • 产品经理能够做好他/她的工作。

所以,我在这儿的目的就是向你展示一些用第三种方式工作的伟大例子。

通常情况下,我会用关键职责和必要的性格特征及技能来阐释,但是在这篇文章里我打算用一种不同的方式,我想向你介绍一些真实存在的人物。

任何在产品领域工作的人都知道,创造产品从来就不是容易的事,但我选了这些特别的例子来说明,一个强大的产品经理能带来非常困难但必不可少的贡献。

这些产品全都是标志性的,每个读到这篇文章的人都会知道我所说的每个产品,但很少有人知道这些产品背后真正的产品经理。知道这些成功产品背后的故事的人就更少了。

之前我从来没有在公共场合讲过这些故事,这些故事是我认为值得去讲的。

这些故事将向你展示一些产品经理做他们工作做得很好的例子。

WORD的MAC版——Martina Lauchengco

在1993年,WORD 6.0是当时发布的最大版本,功能智能,微软在那之前就已经生产好了但直到那时才发布。

除了全部的这些新功能,团队还有另外一个大的目标。他们的代码库已经独立出来,微软要为每个平台(Windows、DOS、MAC)单独实行的话是非常慢且代价很高的。这个代码聚合工作应该为微软节约了大量的开发时间,而且他们试图说服自己——改进产品,因为Word将在每个平台上具有相同的功能。

这也意味着释放的压力很大,所以他们可以开始获得单个代码库的效率。

在那时,WORD的MAC版是一个相对小的市场。相对于Windows超过$1B的市场来说,它只有$60M。

如果你还记得那时,Windows机器绝对占主导地位,甚至APPLE的未来都还是一个不确定的东西。

然而,Mac的社群同样有声有色,有很多它们平台的热情粉丝,同样需要注意的是,这个社区对于微软不怎么爱。

PowerMacs刚刚进入市场,它拥有更快的芯片计算速度和更多的内存。大部分团队开始用这种新的电脑,因为在早期的时候,WORD 6.0 Beta版在常规的电脑上运行太慢了。

当然,大部分的Mac用户群还不是用新的PowerMacs,他们仍然是“常规的”Mac——在那个时候硬件升级周期更慢。

所以,当微软发布的“为Mac准备的最全功能文字处理器”在他们的Mac上只能爬行时——我们说的是两分钟的启动——社区立马在新闻组发帖:微软实际上试图“杀死Mac”。

讨厌的邮件开始无处不在——包括直接给Bill Gate的邮件,Bill Gate会把类似“这是在打压MSFT的股票价格,修理它!”的信息转发给他的团队。

一个刚从Stanford出来的年轻产品经理,Martina Lauchengco加入了,她的主要工作就是来帮助扭转这种局面。

团队很快意识到,获取一个共通的代码库是一个值得的目标,但如果产品的结果不行这就只是一场空欢喜。用户选择他们的设备和平台是因为他们看重这些差异,而不是因为相同性。

从客户的角度来说,他们宁愿等待更长时间,获得一个更好的特定平台的解决方案,而不是同时输出一个全平台的一般产品。

这个团队最终专注于性能,并且吸收了Mac的优势。

自从Mac用户开始超过Windows用户,他们开始着眼于像“何时并且如何加载字体”之类的问题,以保证所有的Mac键盘快捷键仍然能够工作。

他们专注于像“字数统计这种每个出版社人员每天会使用10次”这样的问题,确保它快如闪电,因为出版社将这个功能作为他们的性能晴雨表。他们甚至使它快过Windows上的功能。

结果在2个月的时间里,他们给每个注册用户发布了一个6.1版本,与此同时还有一封由Martina署名的道歉信,以及一张购买折扣券。

这次版本的发布成功的拯救了形象危机,但更重要的是,这个版本真的对Macintosh更好——一个Mac团队都真正感到自豪的产品,Mac 团队认为他们应该首先投放于市场。

这个例子很好的诠释了为用户做正确的事情多困难啊,经常会面临大量的压力,但那正是强大的产品经理应该明白如何去做的地方。

在那随后的几年里,微软不仅再次决定分散代码库,而且他们完全将团队分离去了不同的大楼以及业务部门,他们充分接纳了Mac的全部东西。战略来了一个180度大转弯。

很难去评估这对于微软和APPLE有多么重要。甚至在今天,20多年过去了,许多行业和客户仍然认为无论是Mac用于业务还是个人使用,Word和其它Office都是非常重要的。那个时候就开启了微软和APPLE数十亿美元的双赢局面。全世界有超过10亿的Mac用户以及PC用户使用Office。

Martina在产品管理和产品营销上都取得了非凡的成就。从微软离开后,她去了网景(Netscape),在那里她负责网景浏览器的营销,然后是响云(LoudCloud),现在我可以很高兴的说,她成为我SVGP的搭档已经超过了十年,同时她也在加州大学伯克利分校(UC Berkeley)教授营销学。

同时我要补充的是,很少有在营销方面厉害的人在产品方面也很强,这种组合是十分惊人的。

NETFLIX——Kate Arnold

NETFLIX是我一直以为最喜欢的产品和公司之一。

但是回到1999年,那个时候的NETFLI还非常年轻,总部在Los Gatos,员工不到20个,正处于突破的边缘。他们有两名经验丰富的联合创始人,包括现在传说中的Reed Hastings,但问题是他们被大约30万的订阅量困住了。

本质上他们提供的是同Blockbuster(英国DVD租赁公司)一样的出租付费体验,只不过是Blockbuster的在线版本。总是有一些尝鲜者,以及一些人住的地方没有录像带商店,但当你能够停在本地Blockbuster商店前时,你没有太多理由通过邮政服务来租赁录像带。人们可能会租一次,然后很快就忘了这种服务的存在,并且人们看起来并不愿意去改变。这个团队开始意识到他们的服务还没有好到让人们做出改变。

更糟糕的是,DVD销售开始落后,好莱坞的强烈抵制进一步混乱了这种局面。然后还有物流实现的挑战,DVD质量难以保证的挑战,还要想出一种既覆盖成本和还能盈利的方法全部将这些实现。

Kate Arnold是这个小团队的产品经理,这个团队知道他们需要做出一些不同的事来。

他们大量做的一个测试就是移动到订阅服务。客户注册一个月,就能给他们提供不限量的电影。这足够好到去改变他们的媒体消费习惯吗?

好消息是:Yes!这真的对客户有吸引力。一次包月收费他们就能消费所有的录像带,这听起来非常不错。

坏消息是团队给他们自己造成了一些实际问题。NETFLIX用户大多想要租新发行的电影,这没什么好奇怪的,但对于NETFLIX来说,囤积更贵,他们需要引进如此多新电影的副本,他们很可能很快就会中断资金链。

所以产品挑战变成了他们如何既能让客户看到他们喜爱的电影,又不使公司破产呢?

他们知道他们需要以某种方式,去让客户去想要一种贵而看起来不贵的混合。必要性是发明之母,列队、评分系统、推荐引擎全都来自这种必要性。因为技术驱动创新,产生了新的,更理想的商业模式。

所以团队开始工作了!在三个月的时间里,团队重新设计了网站,引入列队,评分系统,推荐引擎,这些使得NETFLIX成为了一项订阅服务。

他们同样也重写了收费系统来处理每月的订阅模式(一个有趣的小故事是,实际上他们并没有推出这个收费系统,因为他们有三十天的免费试用月,这给他们带来了他们所需要的额外时间)。

有这么多需要改动的东西以及相互关联的努力要做,每天的站立会议几乎包括了公司的每一个人。

与联合创始人一起讨论战略,和用户验证概念,评估分析,和团队讨论特征和功能,与财务探讨新的业务模式,市场收购,以及仓库实现等灯,你可以想象Kate每天的工作量。

然而,团队开始了新服务的运营,并利用这项服务在另一个七年增长和扩张了他们的业务,直到他们过渡自信的转换流模型再次打乱了自己。

Kate应该是第一次信任一个非常惊人的团队,包括一些杰出的工程师,以及创始人的蓝图和勇气,但我可以说,如果没有Kate这种基于技术的解决方法壮大了公司业务,NETFLIX所遇到的好机会几乎不可能发生。这也同是一个伟大的例子——一个产品经理不仅需要同整个公司一起想出产品解决方案,还要想出有用的业务解决方案。

另一个NETFLIX有趣的小故事是——当他们早期资金紧张的时候,他们曾想把自己以$50M的价格卖给Blockbuster,可Blockbuster拒绝了他们。现在Blockbuster已经濒临死亡(13年Blockbuster破产),而NETFLIX估值已超过$40 billion。

Kate现在是纽约市Shutterstock的产品领导者。

GOOGLE ADWORDS – Jane Manning

下一个例子是我最喜爱的一款产品。

我敢肯定你们每一个人都听过Google AdWords。你知道这款产品是谷歌帝国的燃料。更具体一点说, ADwords已经16岁了,去年它的单项收入就已经超过了$50B。

我猜你们大部分人都不知道这个定义了行业的产品是如何形成的,尤其是这款产品如何悄然降临就像从来没有发生过一样。

还是2000年的时候,AdWords项目最困难的部分才达成一致意见,他们能够开始工作。

核心的想法得到了拉里·佩奇的支持,但是这个想法立马遭到了广告销售部以及研发团队的强烈抗议。

Jane Manning 是一个年轻的研发经理,为了这个工作成了产品经理。

隶属于Omid Kordistani的新销售部门,开始向大品牌销售关键字,将其结果置于搜索结果顶部,以广告形式突出显示,尽管其他公司在搜索结果上已经做了很多风格,包括Omid Kordistani之前所在的Netscape ,但这仍然十分突出。销售人员非常担心这种自助服务广告平台的概念会削减销售团队努力销售的价值。

工程师们一直在努力提供高匹配度的搜索结果,同样非常担心用户会对他们搜索结果中的广告感到困惑与沮丧。

Jane和这些人单个坐下聊,去更深的了解他们的担忧。她发现一些人仅仅是对广告感到不舒服,另一些人则担心这种品牌替换。

Jane了解了这些限制以及担心后,她提出了一种既能解决这些问题,也能使无尽的小企业得到一个更有效率的广告解决方案的方法。Jane也了说服Google最早,也是最受尊重的工程师之一,Georges Harik,让他去帮着带领其他工程师。

产品最终将AdWords生成的广告放在搜索结果的一侧,这样他们就不会和显示在搜索结果顶部的销售人员销售的广告混淆。

同时,不再根据付费确定展示位,而是采用每次曝光所支付的价格乘以广告的效果(广告率)来确定展示位,所以效果最好的广告(最有可能与用户相关的广告)将会上升至顶部,最糟糕的广告即便用一个更高的价格也不可能一直展示。

这个解决方案为销售人员明确区分,同时又保证了高质量的搜索结果,无论是有偿的还是有机的。

Jane实际上还给AdWords写了第一份使用细则,并且从AdWords建立到发布,她一直与工程师并肩在一起。

这是另一个说明总是有很多很好的理由去阻碍创建产品的例子。 在成功的产品中,总是有人像Jane一样,在幕后努力克服每一个障碍,无论是技术上的,商业上的还是其他。

Jane结婚后休息了一段时间,现在又再次回到了Google,这一次是帮助You Tube团队。

BBC MOBILE – Alex Pressland

我不得不承认BBC的弱点。他们已经将近100年了,但他们接触科技和互联网较早。我看到很多惊人的产品人都来自于BBC,他们现在遍布在欧洲及之外的地方。

回到2003年,正好是iPhone初次登台前四年,BBC一个年轻的产品经理,Alex Pressland,恰好刚带完一款产品,使BBC成为世界上第一家多平台发布内容的媒体公司。BBC的大部分人都不明白这点的重要性,甚至值得吗?但是Alex明白这种技术能够用新的、出人意料的方式来增加BBC的覆盖面——BBC使命的主要部分。

因为Alex明白基于IP技术多平台联合发布内容的潜力,A她开始研究新的有用方法来投入这项技术。她开始观察在英国还没有被BBC传统广播媒体(家里或者车上的TV或者Radio)覆盖的人。

她发现在城市中心场地有那种很大电子广告牌屏的地方会播放视频。但是她注意到,在这些地方播放的和你在家里电视上能够观看的是同样的东西,尽管环境和观众很不同。

所以Alex打算做一系类的实验,她让她的编辑团队给特定场所的观众整理出一些定制内容,然后她来估量观众的覆盖率和参与度。

尽管这在今天听起来没什么奇怪的,但对当时的BBC广播新闻文化来说,这是一个非常陌生的概念,并且要将BBC往这个方向推,还有很多的障碍,其中最重要是的编辑上的和法律上的。

编辑并不习惯于创建内容然后在不同的环境交付的模式。这是BBC编辑文化的核心,需要充分证明,为什么这对于BBC和观众来说这是一个好事。

法律上过去不允许通过启用IP设备进行分发。 想象一下,内容许可协议堆栈需要更新或重新协商。

Alex实验的结果以及早期的成功,给了Alex自信去让BBC领导阶层实行一个新的产品愿景和战略,她将这个战略称之为“BBC Out Of Home”。

需要提到的是,她是以一个产品经理个人贡献者(individual contributor)的身份去做这些事情。

这项工作最终推动了BBC从广播内容到内容分布戏剧化的转变,这想工作也戏剧性的影响了覆盖面,很快成为了BBC’s Mobile的根基。现在,全世界超过50M人每周依靠BBC’s Mobile。

这不是一个证明技术解决问题的故事,而是一个关于意志力力量的故事。尤其是在那种创建时间很长的大型机构,让它做出本质上的改变是很难的,但也恰恰是强大产品经理应该知道如何去做的地方。

从BBC离开后,Alex在每个技术媒体公司都取得了了不起的成就,现在纽约运营Bauer Xcel Media的产品。

APPLE ITUNES – Camille Hearst

我很乐意为你们介绍另一位非常强大的产品经理——Camille Hearst.

Camille 是Apple iTunes团队的产品经理,你能够想象伴随如此一款具有破坏力和开创性的产品,在Apple塑造产品的这些年她所经历和所学习的有多少,尤其是在iTunes从原始的基于DRM(数字版权管理)音乐到DRM-free 音乐,到成为一款真正大众级的产品的这些年,她发挥了至关重要的作用。

从早期的尝鲜者到进入大众市场涉及到各方面的努力,一些是产品上的,一些是市场上的,一些则连接了两者。产品与市场连接的一个很好的例子是iTunes团队与《美国偶像》节目的接洽。

这对于iTunes团队来说,是为产品做出的最富戏剧性、最明显也是最有挑战性的努力。

在2008年,《美国偶像》成了一个文化符号——超过25M的人一周观看两次,这种重复观看的现象是前所未有的。

Apple 从中为iTunes和数字音乐的力量找到了一个理想的目标市场。不是销售节目中特色选手的音乐,而是将iTunes成为客户生活中完整的一部分。

潜力无限,然而挑战也很大。

这个挑战是iTunes的副总裁——Eddy Cue和其他人完成的,但是 Camille作为产品经理在很多集成方面也帮忙解决问题。

举个例子,《美国偶像》节目全都是关于投票的,Apple很快发现选手的音乐销售情况很有可能强烈暗示了投票结果,虽然通常情况下iTunes都是设计成显示热门音乐以及突出热门标题,但在这件事中要特别注意不能去影响投票。

很显然,这对《美国偶像》的制片人是相当重要的——它将会减少甚至是消除下周哪个选手会继续的悬念。

这个集成同样允许团队去瞄准一个非常具体的人物角色,并推动与这个群体的互动,关键的一点是得到Tunes对于这些还没有安装app的人变得容易了。

刚处理完这些,无尽的其余挑战接踵而至。Camille和她的团队既要想出技术方案来完善《美国偶像》的体验,又要把iTunes 作为一个关键因素注入粉丝的生活。在转变方向之前,这贡献了2014年大约$20 billion的业务。

对于我来说,这是一个产品经理是如何为很困难的问题找到创造性解决方案的伟大案例。

Camille接下来加入了YouTube团队,然后成为Hailo伦敦总部的产品领导,现在我可以很高兴的说她成为了纽约市初创公司KIT的新CEO。

ADOBE CREATIVE CLOUD – Lea Hickman

值得注意的是,到目前为止,这些产品经理展示的独特成果都是作为产品经理的个人贡献——既不是作为董事也不是副总裁。

对于初创或者更小的公司,一般是一个强大的产品团队配备一个强大的产品经理,但是对于大公司,经常会配备更多的产品经理。这需要强大的产品领导力,包括提供宏大的产品视野和战略。

在我们这个行业中,最困难的一项任务是给成功的大型公司带来重大的变化。如果公司真处于一系类的麻烦或者他们正处于痛苦之中,这反而是容易的,因为痛苦能够激发改变。

但一些伟大的公司会在被别人扰乱之前先打破自己。亚马逊,Netfix,谷歌,Facebook与大量趋于死亡的大型公司之间区别就恰恰在于——产品领导力。

在这里我想向你讲的是一个产品领导者的故事——Lea Hickman。在2011年的时候,Lea 正在为Adobe’s Creative Suite带产品。

她帮助Adobe公司创建了一个非常庞大且成功的业务——基于桌面的Creative Suite,每年的授权收益就达到了差不多$2B。

但是Lea 知道市场正在发生变化,公司需要从旧的桌面为中心的年度更新模式,切换至支持设计师现在使用的所有设备——包括平板以及移动设备的所有形式的付费模式。

Lea知道那种更新模式会推着公司把产品带向既不利于Adobe客户,长期来说也不利于Adobe的方向。但是这种量级的改变是相当相当困难的——从Creative Suite 中得到的收益大约是Adobe每年$4B收益的一半。

要知道,在公司这个躯干中的每一处骨骼和肌肉都是为了保护其收益,所以如此量级的改变意味着推着公司远离其舒服的区域——金融,法律,市场,销售,技术——公司中不被涉及的地方很少。

你能够从这个典型的担忧开始:

金融人员会担心从许可模式到订阅模式的收益结果。

开发团队则担心从现在两年一发布的火车模型到持续开发和部署,尤其还要保证质量。他们同时也担心现在服务的责任将会变得更高。

在销售这边还有更大的担心。可以想见,这种转变势必会改变Creative Suite的实际销售方式。不再是一个大的代理渠道,Adobe将会和它们的客户建立起一个直接的联系。虽然Adobe很多人普遍期待这一改变,但销售部门知道这件事情如果不成功将是十分危险的,渠道方面可能不会非常宽容。

不要低估了从客户到销售人员情绪的变化,从“拥有软件”到“租赁方式”。

Creative Suite已存在超过100万客户,Lea了解技术接受曲线,一部分客户群会强烈抵制这种量级的变化。Lea也理解这不仅仅是新的Creative Cloud是否会更好的问题,在某些有意义的方面也会不同,一些人比其他人需要更多的时间来消化这种变化。

正如名字所暗示的,Creative Suite是一系列应用的集成——15款主要的应用以及更小的实用工具。所以这意味着不仅一款产品需要转变,全套产品都需要转换,这戏剧性的增加了风险和复杂度。

所以,大部分公司拒绝处理这种量级的变化还有什么奇怪的吗?

Lea知道在她和她团队面前是一个艰难的工作。她知道,为了使这些内部相互关联的应用能够平行移动到一起,她需要非常清楚的表达一个令人瞩目的愿景——新的整体要好于部分之和。

Lea 和后来Adobe的CTO,Kevin Lynch一起将一些令人瞩目的原型放在一起,来展示这个新基础的力量,并用这来团结领导层和产品团队。

Lea和整个公司的领导以及利益相关者开始了一个持续的、令人疲惫的沟通。对于Lea来说,这并不是过度沟通。持续的原型流使得人们对于这个新东西的未来感到兴奋不已。

由于Creative Cloud的成功——Adobe常续性营收超过$1B,比任何人拥有的都要快——Adobe中断了基于Creative Suite桌面的更新,集中所有的创新到新基础上,现在已经有超过六百万的创意专业人士订阅并依赖于Creative Cloud。Adobe的市值已是转变前的三倍多——现在公司的估值已经超过了五百亿美元,很大程度上得感谢这次转变。

很容易看出拥有大收益的大型公司在风险下做出改变会多么的迟疑,他们需要的不仅仅是存活,而是壮大。Lea解决掉这些担忧后,带着一个清晰的、令人瞩目的愿景与战略以及与利益相关者的清楚持续沟通,昂首向前。

这是我所知道的感到最钦佩、几乎是超人类的例子之一,一个产品经理在一个如此大的成熟的公司,推动了如此重大有意义的变化。

毫无疑问,在我的心中,如果Adobe没有人像Lea一样拼命工作推动这种变化,Adobe不会有今天的地位。

Lea从Adobe离开后,为我们这个星球上正冉冉升起的一颗星星,一家你知道并且喜欢的公司/产品系列——InVision带领产品。

总结

正如我所举的这些例子,每个产品经理都用他们的方式向我强调,他们的团队是多么惊人,单靠个人的努力走向成功是多么的不可能,但是希望这些例子帮助你弄清楚了产品经理真正的、必要的贡献:

我希望你能带走这些大点:

  • 产品管理完全不同于其他管理。它和设计师的贡献是完全不同的,所以让我们停止关于这两个角色是同一个角色的错误讨论。同样,它也不是一个项目经理。有很多项目经理不可避免的会涉及到所有领导的位置,但是抓住项目经理的这一点,则完全忽略了这个角色的本质。我认为产品经理的角色是和CEO的角色最相似的。但和CEO的角色又有很大区别,没有人会向产品经理做汇报。
  • 产品经理就像CEO一样,必须对业务的方方面面有一个很深的理解。产品经理必须保证业务成果,不仅是定义一个产品。这需要对许多内部相关部分都有一个很好的理解,以及业务的限制——金融,市场,销售,法律,合作伙伴,服务,客户环境,技术能力,用户体验,并且想出一个对于客户和业务都有用的解决方案。不要认为这意味着需要一个MBA——事实上不是我描述的每一个产品经理都有一个MBA——或者你自己需要全部的技能,你只是需要对产品会如何影响一个业务有一个宽泛的理解,然后和你的团队以及整个公司一起协作完成所有重要的事。
  • 我希望你注意到这里的每一个例子,成功的解决方案并不来自于用户或者销售,好的产品要和设计、开发紧密结合,用满足你业务需求的方式去为我们用户和客户解决真正的问题。在每一个例子里,用户不知道他们爱上的解决方案实际是可能的。
  • 像一个成功的CEO一样,成功的产品经理必须是聪明、创造力、顽强的最好版本。聪明,我指的是能够运用新技术去覆盖新客户或者获得新的业务模式。创造力,我的意思是用常规产品盒子外的功能去解决业务问题。顽强——用强有力的证据将公司推出他们的舒服区域,面对顽固抵抗的时候能够不断沟通,并跨部门构建桥梁。
  • 最后,我希望你能够明白,真正的领导力是将伟大的产品经理区分于一般产品经理的重要部分。所以不管你的抬头或者级别是什么,如果你想成为伟大的产品经理,就不要害怕去领导。

我向你展示强大的产品经理在工作中的例子,他们创造的产品真正改变了世界。

如果你想在你们公司创造开创性的产品,我希望他们的例子能够告诉你,你真正的工作是什么,以及伟大的产品管理能够导致一个公司的成功的差别在哪里。

原文地址:http://svpg.com/behind-every-great-product/

一个成功的产品团队,最重要的10点特征

一年前我被邀请至布达佩斯,在Craft Conference中做了一个演讲,我谈论了十点关于产品团队为什么会失败的原因。

尽管很多团队认为效率很重要,却依旧效率低下,大部分的产品管理在任何有意义时期都很难“敏捷”起来。因为总体上来说,管理仍然是“瀑布流”的方式。会议组织者今年又把我请回来,继续讨论这个话题,去讨论更多我所知道的——最好的团队是如何工作的。

上个星期我上传了这个演讲,这篇文章是一个叙述版。如果你更爱看视频(一个小时),你能在这里找到演讲。

在第一次演讲之后,有很多人联系到我,问了很多关于选择的东西。除了推荐他们去读我的书,或者参加一个为期2天的研讨班之外,我想不到一个更满意的回答。所以这激发我更深入的思考——一个强大的产品团队中最重要的特征到底是什么,我终于强迫自己想出了十点我认为最重要的特征。

持续探索与交付

正如我讲述了瀑布模型环境下的十大弊端,我也讲了在持续探索与交付模型(同样以“双轨敏捷”著称,或者叫“探索短跑交付冲刺”)环境下成功团队的十大属性。

成功的关键

1、授权产品团队

所有最重要的特征是强大产品团队的绝对基础概念。这到底是什么意思呢?

首先,重要的是团队的持久性;这意味着团队成员不能像棋子一样被移来移去。如果他们想要实际创新,他们需要时间来了解彼此,了解他们的技术、客户以及行业环境。

其次,团队成员之间的情感共鸣是关键。这意味着理解并足够尊重彼此,每个团队成员在贡献、提建议的时候都感到很舒服,挑战自我,促进彼此做得更好。

第三,这意味着团队拥有必要的多样性技能,这些技能常常是指产品管理、用户体验设计以及开发,许多情况下我们还得用上数据分析和用户研究。

最后,尽管对于许多公司这是一个敏感的话题,也很难去争论co-located(同处一室)团队的优势。co-location指的是产品经理、产品设计师、工程师(或者至少是技术领导)全部彼此坐在一起。我们不可能所有的团队都实现co-location,但我们在尝试。同时需要清楚的是,团队跨地点并没有什么问题,只有当单个团队被分裂,导致了速度尤其是创新上的消极影响时才是问题。

2、产品愿景以及战略

为了使产品团队实际被授权并且行为有一定意义的自主性,团队必须对更广泛的行业背景有一个深入的理解。这从一个清楚并有吸引力的产品愿景开始,我们通常把这条实现产品愿景之路称之为产品战略。

产品愿景描述的是我们正努力打造的世界,通常介于2-5年(对于硬件工作则更久)。

产品愿景必须是鼓舞人心的,如果做得好,它将是我们最有效的招聘工具之一,激发员工每天来上班。强大的技术人员会被一个鼓舞人心的愿景所吸引,他们想做一些有意义的事情。

产品战略是指在实现愿景的道路上我们计划输出的产品次序。尝试用一个产品就取悦所有人,这样的策略是十分愚蠢的。相反,对于市场、地理以及人群,我们应该有一个优先列表,我们专注于实现适合每个市场的产品/市场。

你拥有的团队越多,越是需要一个统一的愿景和战略,以便每个团队都能做出好的选择。

最重要的是,产品愿景应该是鼓舞人心的,而产品战略应该是有非常有目的性的。

3、专注于业务成果

为了能够做出好的决定,一个被授权的、有自主性的团队所需要的业务环境的第二部分,是设置业务目标的优先顺序。OKR系统(Objectives and Key Results)正好有助于促进这些。

OKR反映了团队正在解决的详细业务问题列表。这些不是功能,功能只是这些问题的潜在解决方法,开发一个功能不是一个团队的成功,解决真正的商业问题才是。

这些绩效管理技术背后的两个原则是:首先,如果你给团队的是需要他们解决的问题,而不是给他们解决方法的话,团队将会表现得更好;其次,用结果衡量团队,而不是产量。在路线图中输出功能是产量,解决业务问题则是结果。

4、合格的产品经理

可悲的是,许多工程师从未有一个机会和一个有能力的产品经理一起工作。那些有过的工程师们坚信他们团队中有这样的产品经理。糟糕的是,许多的工程师甚至不知道产品经理应该给团队贡献什么。

这样考虑吧。为了产品团队解决复杂的业务问题,仅仅是技术上的解决方案是不够的,客户喜欢也同样是不够的,最困难的是,解决方案必须真正为你的业务工作。

想一想这意味什么。想象你正在为Uber、Airbnb工作,你必须面对复杂的法律、工会以及贸易组织。或者eBay,不得不面对一些重大的限制条件,来被归类为市场而不是一个电子商务网站。或者Tesla不得不面对自动导航仪的责任问题。每个公司都有一个关于这些限制条件类型的列表。

有法律限制,金融限制,销售和定价限制,品牌和市场限制,隐私限制,安全限制,合作契约条件等等。

不幸的是,很多情况下唯一能够完成这项工作的人是CEO,这样的话你就可以想象,为什么他或她真正授权给团队做决定时会感觉到不舒服。

那团队应该如何做呢?有三种选择:一是CEO或者其它的执行人员决定一切。二是无能的产品经理安排一个大的会议,邀请高管们参加,让他们讨论出结果——这就是所谓的由委员会设计——他们一贯只会产生糟糕的结果。三是产品经理做好自己份内的工作,学习这些限制条款,把它们带入团队,以便产品团队能够明白解决问题的最好方案。

结合对技术的深入理解、对用户和客户的深刻认识,你就能够明白为什么这是一个艰难的工作。这也同样是一个强大产品团队的关键,尤其是如果团队想要任何意义的自治的话。

5.协同驱动(collaboration-driven)解决方法

我在这里不是将”collaboration”作为一个流行语在讲。我这样说的意思不是指一个产品经理整合需求(“requirements”),一个设计师设计漂亮的东西,工程师在那里写代码,相反的是指三种技能——产品、设计和开发——真正协同起来解决问题。这是因为有了好的解决方法,技术驱动功能和功能驱动技术是一样的。技术能动设计选择和设计驱动技术选择是一样的。设计指导驱动功能和它反过来也是一样的。

关键在于技术、用户体验设计以及功能全都十分错综复杂,只有在这三者之间反复交换意见才能得出一个好的解决方法。

协同驱动(collaboration-driven)解决方法是co-located团队能够持续胜出分布式团队的唯一最大理由。

6.产品发现:快速学习

许多伟大的产品归结于团队快速试验大量想法的能力。我们想要快速的将好想法从糟糕的想法中分离出来。产品发现是一套广泛的方法,旨在帮助我们快速学习哪些想法能飞,哪些想法不那么好。一些想法是大的,一些想法是小的,一些是冒险的,一些是昂贵的。有时候我们需要论证,有时候我们只是需要证据。

很多人用不同的方式描述这个产品发现,一些人喜欢将其描述成“成功之前先假装成功(fake it before you make it)”,一些人则喜欢强调“做事从小事做起(build things that don’t scale)”。关键在于我们需要快速学习、减少浪费。

用开发团队来创建并发行一个真正的产品来试验一个想法,是一种最慢、最昂贵的学习方法。

7.关注关键风险

关于产品发现,这里有两个重要的点需要强调一下:

首先我们需要关注四大关键风险:价值风险——会有人买或者选择使用它吗?可用性风险——他们能够明白如何使用吗?可行性风险——我们的工程师能用已有的科技、时间和技术实现它吗?以及项目干系人(stakeholder)风险——公司不同部门的人同意这个解决方案吗?

在产品发现期间,我们将为这四个问题找到好的答案。如果找到了,我们就有了我们让研发团队花费时间创建并提供一个高质量产品并衡量解决方法的证据以及自信。

8.MVP的角色

MVP的概念是产品中最重要的概念之一,同时也是最受虐最容易误解的概念。

概括总是有风险的,但是我将在这儿冒着风险,提出“MVP不应该是一个产品”。在每一个我遇到的案子里,当团队花费时间和钱去建立一个真实的QA’d产品作为他们的MVP时,我总是能在事后为他们展示如何用更少的成本和浪费来完成同样的学习。

所以,MVP是一个实验,一个测试。它是常用的原型样式之一,通常是一个用户原型,有时是一个实时数据原型,有时是一个可用性原型。有时它们是会混合在一起。在每个案例中,它只是真实建立一个真正产品的一部分。

9.产品交付:释放信心

我站在这里不是告诉开发者如何去建立并发布软件。正好相反,在上一个问题(团队用开发部门来创建这些MVP产品)所带来的问题之一,是开发团队经常被迫发布一些他们知道不是他们真正应该发布的软件。这不是他们站在后面感到舒服的产品。也许是主要的可靠性问题,或者比例问题,或者性能问题。但产品经理总是说:“这只是一个MVP,所以放松点!”

我在这里建议,当客户实际依赖于这款软件来经营自己的业务时,你不应该妥协。我们有很多好的产品发现技术测试MVP’s,这些方式能保护我们的客户,我们的收入,我们的声誉和我们自己的员工。

因此,使用您的最佳实践,并且只有当您对该版本具有必要的信心时,才能将真实产品发布到生产环境。

10.以客户为中心

我想说的最后一点有点不同。几乎我遇见的每家公司都告诉我他们有多爱客户,在他们的公司价值以及使命陈述中也能找到这点,但我要告诉你的是,说来容易做来难。

当我和团队交流的时候,我会说得特别快:如果出现了一个客户产品问题,他们如何回应?紧急程度是什么样的?团队有直接与客户联系以理解他们是否需要吗?团队成员知道客户的名字吗?他们与客户之间是什么样的关系类型?他们把客户当成一种大的痛苦,还是他们认为客户更像同事?

为客户灌输这种真正的同理心和承诺的最好方法是将团队,包括开发人员,直接连接到客户。

我希望这些能让你更好地了解什么使伟大的产品团队伟大。

原文地址:http://svpg.com/product-success/