【4026】产品原则就是产品的宪法

最近听了几段罗辑思维的脱口秀,其中一段讲美国建国初期,几位老大们昏天暗地开了4个月的会,制定美国宪法的故事,这个宪法,nb就nb在短短几百个字,用了200多年,只添加了一些修正案。

这事儿给了我启发。

国家需要宪法,而国家也可以看作一个产品,那么,产品的宪法是什么?翻开《启示录》,我知道了,就是产品原则

美国宪法

首先,我们要简单说下为什么要有产品原则这个东西,美国宪法的序言说——

我们合众国人民(文图的We the People就是全文的前三个词),为建立更完善的联盟,树立正义,保障国内安宁,提供共同防务,促进公共福利,并使我们自己和后代得享自由的幸福,特为美利坚合众国制定本宪法。

 

然后,要确定产品的价值观。

总结起来,美国宪法的价值观就是七条——人民主权、共和制、联邦制、三权分立、制约与均衡、有限政府、个人权利。举例第七条,就是说“个人有言论自由和新闻自由等”。

对于你的产品,比如说就是“小组是成员们的私人领地,管理员尽量不要干涉(豆瓣)”、“每个人都可以在某时某刻成为别人的老师(知乎)”、“有激情有方法的人,做自己想做的事,效率会高于完成任务(阿里赛马)”等。

 

接着,是实现产品目标的方法论。

比如,产品团队是如何组成与分工的——“实行资产阶级性质的联邦制,肯定了以立法、行政、司法三权分立。规定立法权属于美国国会,并规定了国会的组成;行政权属于美国总统,以及规定总统产生的办法;司法权属于美国联邦最高法院,并规定最高法院的组成;各州的相互关系和义务。”

又如,如何做产品决策——“美国宪法明确了由选举产生的政府具有唯一的合法性。人民通过选举或者指定产生的政府官员和议员来行使权力。”

 

你的产品,还需要想清楚,目标用户是谁?有哪几种,他们的优先级如何排序?产品未来一段时间的目标是赚钱、还是烧钱获取更多用户?……

 

随着时间的变化,产品所处的市场环境、竞争对手、用户属性也会不断变化,所以,还必须要有一个产品原则的迭代优化机制。所以,美国宪法也提供了修正案提出和通过的程序,议员们也可以修改美国宪法和其他基本法律,甚至还可以重新起草新的宪法。

 

产品原则,是整个产品团队必须达成共识的东西,我们在工作中的大部分争吵,追根溯源,都是产品原则不一致,比如你认为卖家重要、他认为买家重要,你认为要拉新用户、他认为要先留老用户……

对产品原则,哦不,是美国宪法感兴趣的同学,可以看这里,确实是体会一个大产品架构设计的好案例。

iamsujie的各种二维码
iamsujie的各种二维码

翻译的一些技巧 from @七印部落

这篇比较奇怪,我在翻看《启示录:打造用户喜爱的产品》的时候,发现试译反馈也有很多有价值的东西,所以不妨贴出来。

Inspired》试译反馈

两种语言的特点:英文精确,中文简洁

英文精确,表现为句子的修饰成份多,语法要求严格。切不可逐字翻译,直译必然啰嗦,变成翻译腔,满纸都是“一个”、“当……的时候”……

试举一例:

The product was a complete failure in the marketplace.

原译文:这个产品在市场上是一次彻头彻尾的失败。

1. 繁改简:这个产品在市场上彻头彻尾地失败了。

[能够去掉的“a/一次,尽量去掉]

2. 润色: 这款产品在市场上彻底失败了。

中文简洁、流畅,重在写意。英译汉要译涵义、译气势,不能译词、译字。我们的目标:往大了说,要保持中文的纯净,往小了说,要让读者读着顺溜。提示:遇到译不顺的句子,回忆一下咱中国人日常生活怎么表达的。

再举大家试译稿中的几例,翻译没有统一的标准,仅供大家参考:

1. In the mid 1980s, I was a young software developer working for HP on a high-profile product.

原译文:20世纪80年代中期,我在惠普是一个年轻的软件开发工程师,做一个概念性的产品。

参考译文:20世纪80年代中期我还年轻,在惠普担任软件开发工程师,参与开发一款备受瞩目的产品。 [能够去掉的“a/一个,尽量去掉]

2. It was when Artificial Intelligence was all the rage, and I was fortunate enough to be working at one of the industry’s best companies, as part of a very strong software engineering team (several members of that team went on to substantial success in companies across the industry).

原译文:那时候人们对于人工智能很狂热,我有幸工作于业界最好的公司之一,并且成为了非常强大的软件工程师团队(这个团队中的数名成员后来在业界取得了重大的成功)中的一员。

参考译文:当时人工智能风靡一时,我有幸进入业界最好的公司,加入优秀的软件开发团队(许多同事后来成为业界的中流砥柱)。

3. Our assignment was a difficult one: to deliver software on a low-cost, general-purpose workstation that until then required a special-purpose hardware/software combination that cost over $100,000 per user—a price few could afford.

原译文:我们的工作比较困难:开发一个在低成本、通用工作站上运行的软件,而同类软件要求特殊的硬件和软件的配合,每个用户的花费超过10万美金这个价格是很少有人能够负担得起的。

参考译文:我们的任务难度不小:为低成本的通用工作站开发软件。当时市场上都是软硬件结合的专用产品,每个用户的花费超过10万美金——鲜有人负担得起。

4. The team was of course frustrated with this outcome. But soon we began to ask some important questions: Who decides what products we should actually build? How do they decide? How do they know that what we build will be useful?

原译文:对于这个结果,我们团队感到非常的失败。但很快我们就开始思考如下问题:谁对我们开发什么产品有决定权?

参考译文:这个结果当然让我们觉得非常沮丧。但很快我们就开始思考如下问题:谁有权决定开发什么产品?

[能用最简单的++结构表达的句子,尽量用这种形式。对(于)……”这样的结构,能不用,尽量不用。]

5. Our young team learned something very profound—something I’m sure many teams have discovered the hard way: It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.

原译文:我们年轻的团队在反省中获得了巨大的认识,我相信这些认识很多团队通过犯错也发现了:你所在的团队有多出色不是最重要的,重要的是你们开发产品是否真的值得你们为它花费时间。

参考译文:我们年轻的团队汲取了深刻的教训,我相信很多团队也从失败中得到了同样的教训:团队有多出色不是最重要的,重要的是开发的产品是否真的值得大家花费时间。

[多余的代词、主语(你所在的、你们)能去掉的尽量去掉。]

6. More generally, we learned that it’s not enough to do a good job engineering a product. At least as important is discovering a product that is valuable, usable, and feasible.

原译文:不仅如此,我们也了解到,出色地完成一个产品的设计任务并不够,至少,发掘有价值的、有用的与可行的产品也是同样重要。

参考译文:不仅如此,我们认识到光做出产品来还不够,还要确认产品是有价值的、可用的、可行的。

7. I promised myself that never again would I work so hard on a product unless I knew the product would be something that users and customers wanted.

原译文:我承诺自己,除非我已清楚地知道产品为用户和客户所需要,否则我再也不会为之盲目投入大量精力。

参考译文:我暗下决心,除非我清楚地知道产品是用户和客户需要的,否则我再也不会盲目投入大量精力。

[第一个…………”…………”的意思,读起来绕口,译文尽量少用;第二个为之有上下文作背景,可以省略。]

8. Soon after I left eBay, I started getting calls from product organizations wanting to improve how they produced products. As I began working with these companies, I discovered that there was a tremendous difference between how the best companies produced products, and how most companies produced them.

原译文:在我从易趣离职后不久,我开始接到一些产品团队打来的电话,这些团队希望能改善产品的工作方法。当我开始与这些公司合作时,我发现,最优秀的公司与其他大多数公司在产品工作方式上存在着巨大的差异。

参考译文:我离开易趣不久,开始接到一些产品团队打来的电话,希望改善他们的产品生产方法。我开始与他们合作,发现最优秀的公司与其他大多数公司在产品工作方式上存在着巨大的差异。

[……之后,从……,当……时候,这类介词短语无端使句子结构变复杂,译文能不用尽量不用。中文很灵活,不要被英文捆住了。]

9. I also discovered that there was precious little help available, either from academia, including the best business school programs, or from industry organizations, which seemed hopelessly stuck in the failed models of the past—just like the one I worked in at HP.

原译文:我也发现对此其实鲜有帮助,无论是学术机构,包括最好的商学院项目,亦或是行业组织,那些曾经在旧模式之中窘迫无助就像是我工作过的惠普。

参考译文:我也发现无论是学术机构,包括最好的商学院课程,还是那些因循守旧、无法自拔的行业组织,像我工作过的惠普,几乎都帮不上什么忙。

【8039】产品探索日记

一句话点评:如此美好的产品探索过程,我想,在很多公司根本不存在吧,哈哈~~~

Marty Cagan发表于2008年11月12日,原文链接,译者:吉绚 / 审校:林航 徐定翔​

产品经理和设计师们放弃原有的线性、瀑布式的开发流程,转而采用我倡导的这种更具迭代性、探索性的流程后,通常需要花一些时间才能适应它的快节奏,掌握产品探索的韵律。

这篇文章将再现产品探索的情景,让大家了解其核心内容。

因为产品的开发过程涉及的因素太多(如产品类型、投入的精力等),做这样的概括并不容易。我尽量使用比较典型和普遍的情景。为了覆盖尽可能多的要点,我构思了以下情景。

============ 第一周 ============
====== 周一

l 为了明确商业目标,我和项目的主要负责人一起进行了产品的机会评估与讨论。

2 与项目的首席设计师及主程序员开第一次讨论会,制定出产品原则。

3 紧接着,我们进行了头脑风暴,想到不少好点子。

4 与首席设计师一起创建第一轮关键人物角色。

====== 周二

l 和首席设计师继续优化前一天完成的用户角色,确定主要和次要角色;讨论用户使用产品的情景,并列出主要情景和次要情景。

2 与用户研究员一起明确潜在特约客户名单;通过电话联系特约客户,筛选候选人。

3 首席设计师根据讨论结果快速创建产品原型。

====== 周三

l 我、首席设计师以及主程序员一起检查前一天完成的产品原型,看它是否符合我们最初模拟的几个用户情景。讨论非常激烈,原型远比我们设想的要复杂。

2 我们回顾之前提出的产品原则,再一次明确了重点,之后大幅简化了产品原型。

====== 周四

l 我、设计师和项目的主要负责人一起查看产品原型。这个原型还在初期,但是已经包含了三个最重要的使用场景。通过讨论,我们意识到我们和项目负责人的想法有些脱节,因为双方对用户的理解不同。

2 继续电话联系目标客户,确认6家公司成为我们的特约客户。最棒的是,他们似乎对我们的产品将解决的问题有极大的兴趣,因为他们的公司都还没有找到好的解决办法。如果我们的产品能够解决这个问题,那么他们会非常看好我们的产品。

====== 周五

l 我们和主程序员一起评估修改后的原型。他对主要功能的可行性持谨慎乐观的态度,并提出了两个重要的问题。第一,其中一项功能的开发成本可能颇高,而且执行 速度很慢。他需要点时间研究这个问题。另外,他认为我们可以省去一些收集数据的工夫,因为我们需要的数据可以从数据库提取。

2 咨询有关法律人士,向他展示原型,确保模型没有和法律相冲突的地方。他们认为其中一处需要进行详细评测,检查结果会在下周给出。

============ 第二周 ============

====== 周一

l 早上,我、首席设计师以及项目负责人一起拜访第一个客户,请四位潜在用户试用产品原型。这次测试收获颇丰。可惜原型的表现与我们的期望还有很大的差距。我 们发现自己此前对用户的理解还很肤浅,项目负责人的理解也不完全正确。现在我们对用户的理解又进一了步,而且达成了基本的共识。

2  回到公司后,我们立刻讨论如何修改原型。我们简化了自以为重要的场景,修改了术语,去掉了那些根本不会被用到的高级功能。

====== 周二

l 主程序员在研究完高风险的技术问题后,确定他之前的担心是有道理的。他提出了新的可行方案,可以实现同样的效果,而且开发难度更低。于是我们根据他的意见对原型进行了调整。另外,他确认了我们本来要收集的数据在数据库中都能找到,这就进一步简化了原型。

2 下午我们拜访了另一个客户,请三位用户参与了测试。今天的情况比昨天要好很多。我们仍然不确定原型的交互设计是不是足够好,但是至少用户能够完成主要任务 了。之前去掉高级功能的这一步棋确实走对了,因为用户并不关心它们。我很高兴我们坚持了以客户为中心的价值观。有两位测试用户希望我们第一时间通知他们产 品完成的消息。

====== 周三

l 与首席设计师、主程序员碰头,讨论目前的成果和接下来的工作。主程序员又提出了一项针对关键流程的优化建议,恰好解决了首席设计师面临的几个棘手的问题。

2 我和首席设计师向视觉设计师提出了我们对视觉设计的几点想法。经过先前的用户测试,我们认为必须将产品中的两个基本概念用某种方式清晰地传达给用户,并且 给出了关键状态和用户可能做出的动作。视觉设计师说她已经有了可以表达这些概念,提升产品价值的想法。她会在接下来的一两天内给我们一些具体的方案,之后 我们可以为这些方案提建议。

====== 周四

l 我们仍然在努力定义基本产品。我们相信已经把最关键的功能都涵盖在内了,但是不确定到底要不要再加上一个比较酷的功能,不知道它是不是必需的。我们计划暂时从模型中删除这个功能,看看测试的效果如何。

2 下午,我们拜访了另一位客户,请三位用户测试了产品原型。原型的可用性已经很棒了,但是,删除了之前说的那个功能后,原型没有得到用户的热烈响应。我们又 展示了之前的版本,这次他们表现出了极大热情。我们得出的结论是,这个功能确实非常重要。我们的原型中已经尽可能地删掉了所有不需要的部分,但是仍然能激 发人们的购买欲望。我们去除了很多高级的功能,简化了关键流程,应该能在主程序员估计的时间内完成开发任务。

====== 周五:

l 我、首席设计师与可视化设计师一起讨论了她设计的方案,我们特别喜欢其中的一个方案。稍做调整洁后,我们把它用在了原型上。

2 主程序员根据现有(也可能是最终)的原型估计出了产品开发的周期。这个时间可以接受,并且有风险的技术问题已经排除。

============ 第三周 ============

====== 周一

l 我们将包含最新的产品原型展示给项目负责人,并且总结了最终的产品设计(包括最新的界面设计),以及所有来自测试客户的反馈。她很喜欢这个产品,希望旁观下午的测试。她也想就价格和定位询问客户的意见。

2 下午,我、首席设计师以及项目负责人带着最终原型去见另一个客户。我们请四、五位用户进行了测试,得到了理想的反馈——没有遇到使用问题,对功能和价值的反响也很好。所有用户都很期待这款产品的问世,也愿意推荐给朋友或者同事使用。

====== 周二

l 继续完善原型,并将这些天来了解到的关键点录入项目维基。

2 向给更多的项目参与人展示了产品原型,包括法律顾问、市场部、产品管理和工程方面的副总。他们提出了一些问题,但都认可用户测试的反馈。

====== 周三

l 我、首席设计师以及主程序员碰头,讨论如何撰写产品文档,方便开发人员、测试人员、部署人员开展工作。

2 我和首席设计师分工撰写文档,我们将各自负责的部分写到项目维基里,并添加了一些对产品原型的链接和注释。

看完以上的日记,希望你能明确以下这10点。

1. 在项目开始时,确定你对目标有清晰的理解(产品机会评估)。

2. 从产品探索最开始时就建立和首席设计师、主程序员的密切合作。

3. 注重真正的协作交流,而不仅仅满足于写那些没人看的文档。

4. 迅速的将关键的产品理念融入到原型的制作中。

5. 设法验证自己对产品的假设,不要纸上谈兵,尽快判断哪些假设正确,哪些不正确。

6. 尽早反复地将产品原型提供给目标客户测试,及早发现问题。

7. 记住要确定基本产品。

8. 产品探索的目标:确定产品是有价值的、可用的、可行的。

9. 在产品探索的过程中不断保持和相关部门的信息互通,向大家展示不断更新的产品原型,让他们了解进度。

10. 不要把时间花在为开发人员写文档上,等到产品确定后再写。

当然了,实际项目不一定完全与我的描述相同,我希望传达这样一种观念:在把产品理念展示给真正的用户之前,不应该花两周时间撰写产品文档,更不能花三周时间制作初期产品原型。

产品探索有特定的节奏和规律,它以构思产品设计、原型制作、用户测试,以及最重要的一点,反复学习为基础。如果你还没有亲身体验过探索产品的过程,那么我希望这篇文章可以让你大致了解产品探索是什么,以及它与直接开始撰写产品文档的做法的区别。

本文节选自《启示录:打造用户喜爱的产品》作者Marty Cagan的博客。该书从人员、流程、产品三个角度介绍了现代软件(互联网)产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。