实战：产品的“加减法”该怎么做

实战：产品的“加减法”该怎么做？

怎样才能让产品不那么臃肿，把产品做得更简练，更生动，这种事从来没有太确切的指南或者指标。我已经见过太多成熟的公司移除产品的各种性能了。他们要鉴别、区分、权衡产品的每一个功能，然后做艰难的决定——应该移除哪个功能。只有这样，他们才能达成“制作更好的产品”的目标。用户vs开发者倘若一款产品的某个现存的特征正处在存亡关头，那我们审视的时候就有必要把这个特征对于使用者的影响和对制作者的影响分开看待。虽然大多数情况下顾客和公司的目标是相同的，但也不全然是。Quora曾在几年前遇到过这样的窘境。当时问题出在DirectQuestion这个功能上。DirectQuestion是让用户直接通过人物主页向Quora用户提问的功能。对用户而言，这个性能放低了门槛，节省了麻烦。他们可以通过这个功能向某位特定的用户直接提问。但这个功能最后被移除了，因为公司发现如果用户之间可以直接提问，那么很多有价值的信息就不会出现在Quora的问题主页上了。这个性能就是个典型的例子：它对用户来说是十分便捷的，但却对公司创造的有价值的内容造成了不利。真实用户vs理想用户那些你所定义的“目标人群”用户往往不是你的产品的第一批使用者。也许你很了解他们，也有可靠的理由证明为什么你更倾向于你“理想中的用户”，而不是他们。一款产品的用户使用时间是有自然期限和循环的(也就是早期和后期用户)，但最重要的是你不能被早期用户的特性左右了你的原定计划。你要继续保持产品的特点，根据你一开始锁定的“目标人群”继续创造和改善它，增添新的性能。既要为早期用户着想，保留他们喜爱的性能，但也要针对你后期的用户继续精心打造产品。你要在这两者间拿捏好分寸。因为给一款产品增添过多的性能往往意味着你日后需要移除它们。移植vs移除近日，开发者有对权衡的问题愈发敏感的趋势。他们不再彻底剔除某个性能；他们选择把这些性能转换为新的产品。Dropbox就用过这个方法开发了照片分享专用软件Carousel，Facebook也同理推出了Messenger，Foursqure则是Swarm。尽管我们中大多数人做不到如法制炮模仿这个战略，但它为我们强调了保持产品简洁生动的重要性——尤其是装载在手机上的应用。手机版vs网页版近日来，我和几位智能产业的创业家谈了谈。他们都想把他们的第一款网页产品改造成手机专用版。由于手机版和普通浏览器版产品的运作方式实在差太大，两者之间无论是外观还是使用模式都截然不同。设计产品是究竟应该从手机版应用上删除哪些性能，这对于制作人来说也是一个令人头疼的问题。Twitter在这方面就做得很好。先看看其网页版应用。网页版覆盖的面较广，子菜单项高达13个。开发者也意识到要把这么多设定都加在手机版上的话那使用太过麻烦，应用本身也难免显得臃肿。Twitter不得不做出决策，把具体哪些功能剥离开来保留在手机版应用中。要权衡在某个平台上移除产品的哪些性能总是一个艰难的决定，因为你需要把产品做得尽可能精简，但用户体验又不亚于你产品的其他任何一个版本。于是就有了技术方面的挑战……当你权衡功能的去留并做决定时，你必须顾虑到每一个细节，再三斟酌。而且几乎每一个功能都是有现实的技术限制和要求的。每当你在制作一个新的功能的时候，你就等于是和产品的未来定下了条约：你要让你现在所编写的东西到了将来也不会过时，而且能和你以后增添的性能兼容。区区几个新功能就能让一款简单的软件对人的依赖性增大，资源人力有限的制作团队可能会力不从心。支持的OS版本，加载时间，遗留成本，定标等等等等，对于软件的功能我还能举出好多好多。很多时候，减少技术上麻烦的部分，或者剔除效果不理想的功能的真正意义在于大幅度节省资源，好将有限的资源用在现存的、更受欢迎、更有前途的性能上。Quibb早期的功能里有一项是用来解析那些非Quibb用户但现存Quibb用户关注的Twitter用户的个人简介。如果我能把他们的公司名对上号，那我就可以基本确定他们是同事，所以那个人是他们会邀请的人。但过一段时间后，我意识到这个功能会引发不少问题。用户们纷纷抱怨他们的消息加载速度太慢。在权衡利弊之后，我删除了这个功能。当时我没有足够的资源来弥补这个问题好让软件能靠有限的技术含量更好地运行，而且仅有的资源有更好更有价值的用途。历史证明，在一定范围内，对任何一位产品设计师而言，精简二字是最艰难的任务之一。这篇文章是我在读了BenHorowitz的“GoodProductManager