翻译#2|打造产品

原文地址:medium

原文作者:Julie Zhuo

译者:max

不足和错误始终存在,请多指正,转载请注明出处

我最近在TNW的欧洲场做了一场演讲,是关于我们在Facebook,用于帮助专注产品设计流程的框架工具。准备演讲的过程让我想到了这些年里所吸收理解的,关于如何打造出色产品的一些经验。

这份指南肯定会有遗漏或者疏忽。如果真的存在完美的产品指导手册(步骤1:抓住灵感;步骤2:***;步骤3:搞定!),那我们一定会拿出去卖个好价钱,接着坐等无数完美的产品,在我们身边出现。

旅途才刚刚开始,吾将上下而求索。

基本规则

  • 产品的成功,是因为他解决了人们的问题。听起来好像很基础,但它却是理解和打造产品最最重要的一点。
  • 打造全新产品的第一步,是理解你想要解决的问题,以及解决的对象。在开始思考任何解决方案之前,你心里必须绝对清楚。
  • 第二个扪心自问的问题:“为什么单单这个问题值得优先解决?”
  • 如果你的目标用户定位很狭窄(或者你是其中之一用户),那你或许可以依靠你的直觉去做产品决策或者判断。否则,你需要依赖于调研、数据来考虑你的决策。
  • 如果你是白手起家的创业者,选择先为相对狭窄的用户群解决问题,会更容易。等你具备种子用户之后,在扩张到更大的受众。
  • 你试图解决的这个问题,应该通过一两个句子就可以描述,并且可以和你的目标用户产生共鸣。如果不行,那么问题还是很大的。

执行阶段

  • 好的执行在于,以尽可能短的时间,得到最可信的结论。
  • 糟糕的执行是,当你尝试某事失败时,同时:
    • 你不能从中吸取教训,从而应用到将来的计划中去。(因为你不清楚为什么失败)
    • 你花了一年时间学会了一项经验,而有条捷径可以让你3个月就能学会。
  • 区分成功、不成功团队的,不是他们是否做然后失败了(当然这是肯定的),而是他们是否能够持续产出。
  • 在为某个特定问题思考解决方案时,先寻求广度,再考虑深度。在确定最终方案之前,头脑风暴10个20个50个解决方案。最开始的5个通常是平淡无奇,当你开始第11个、20个、50个时,奇迹才会发生。
  • 当你陈述产品计划并且有人问:“有考虑过尝试xx吗?”而你回答“没有”,那也很危险,因为你的探索过程还是不够严谨。
  • 运用经验,帮助你缩小头脑风暴中正确答案的范围。(比如,取出排名前几位的创意,制作原型,放在用户面前并观察他们的反应)
  • 一旦你确定了想要执行下去的方案,把它放到产品框架中进行假设——如果决定加入,会发生什么?(比如:我们要解决的问题是,市民们想要了解每周末当地的一些活动。我们的假设是通过电邮的方式,触及x%的用户。)
  • 你应该不间断的寻找检验你假设的短周期。你能向路人展示你的想法,并判断是否易懂吗?你能组织一场针对用户的调查,来判断是否有足够多的人群对你的创意足够感兴趣?你能快速建立一个帮助你获得清晰结论的版本吗,即使跟你预想的完成版相比要简陋很多?
  • 一旦假设拥有了明确积极的暗示,别着急于把测试内容上线。相反,制定一个明确的上线标准。当功能被打磨测试之后,达到什么标准,才可以正式上线。
  • 当你着手于涉及很多改变的大计划时,尝试是否可以把改变划分成很小的、独立的、可测试的阶段性目标。不要掉进这样的陷阱:做出5处改变,结果糟糕,结果还需要去理清是哪几个变化导致了问题。
  • 不管项目成功与否,每个项目都做一次“事后诸葛”。学到了什么产品经验?具体是什么方面经验?将来你会有哪些修正?然后向全公司分享。

评判成功

  • 如何评判成功对于长期团队来说尤为重要,因为大家会聚集在一起。确保在合适时间和合适关注度下进行。
  • 在上线之前定义好怎么样的数据可以算作成功。如果在上线之后再确定标准,你的想法将会显得不那么客观。
  • 对于每个成功节点,设计一个好的衡量标准来证明你不仅仅是在数据上拆东墙补西墙。
  • 如果一项重要数据超出预期(不分好坏),第一个问题是“为什么?”在完全理解清楚原因之前,不要有任何的促进或者打压措施。
  • 运用“水晶球”方法找到合适的方法去衡量成功。自问“如果我可以知道任何关于用户使用我产品的事实,那我会想知道什么来确定产品是成功的?”(通常人们的答案不是点击率而是更抽象的比如我的产品体现了多少价值)从问题的答案,反推一个可量化的测量标准,从而更好的评估你的目标。
  • 你的目标应当始终根据你的最新情报来制定,快速更新。提前主动确立总是要好过之后被动调整和执行。
  • 当你发现总是和队友关于产品方向产生争论时,根源很可能在于你们衡量成功的方法有分歧。尝试能否用新的方法或者角度表达你的想法。
  • 想要知道产品是否符合市场(试图优化或者扩张),你最好多多关注留存率,而不是参与度之类的数据。

团队驱动

  • 带入团队角色去思考(设计需要去做什么?工程师需要去完成什么?)将会限制你提升自己的能力。相反,去思考“我做什么会最大限度帮助团队成功?
  • 喜欢解决问题的团队会比喜欢一个解决方案的团队拥有更成功的产出。因为如果知道一个问题值得解决,在团队没有想到解决方案时始终具有驱动力,即使团队的第一第二个解决方案并不是最好的。
  • 总是以善意待人。我想说,每个人都想要同样东西——创造很棒的产品。也许你有极小的可能判断错误,但你也从不必要的闹剧中脱身了。
  • 了解你的长处和特点,以及队友的特长。再根据成员的特长来划分工作任务和责任。
  • 良好沟通是健康团队的关键。每个成员都应该感觉可以畅所欲言,哪怕这些观点是错误的。观点多样性是去的最好结果的基础。所以不要害怕表达自己的观点,不要害怕重复观点,如果你没有听清,同时也为队友创造相对安全的环境。

Some rights reserved
Except where otherwise noted, content on this page is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license