难在哪？
- 运营／市场人不懂难产品。
- 产品／研发人写不好文章。
运营／市场人，文字能力强、熟悉读者，但是对于产品的内在逻辑和呈现方式，往往比较差。由他们操刀的产品介绍，常会拘泥于“我们提供了xxx和xxx功能”，“帮您解决了xxx和xxx问题”以及“有效提升工作效率，帮助企业xxx”。
大家不妨用一个标准来衡量一下：
把这段文字的产品名换成竞品，是否毫无违和感？
如果是，那这就是一篇不痛不痒的泛泛之谈而已。有时候，笔者也能意识到这种问题，那么就开始加入大量的专业名词／场景描述，洋洋洒洒写了一大篇，会非常啰嗦，失去了简洁的美感。
产品／研发又往往由于对产品太熟悉，陷入到工程师思维中去。同时，太过专业化的描述也会给理解带来很大困难。
当然，文无第一武无第二，文章好与坏和技巧因人而异，我只是分享一些自己在写作过程中的技巧和要点。
写的像个工程师，而不是销售
有的产品介绍的文章，很标准，很套路，非常像销售的话术。实际上，如果我们想要写别人能记住的文章，一定要足够的独特和有深度。千篇一律不过是对已有内容的重复和搬运，毫无疑问是劳动力的浪费。
我说写得像个工程师，是要求作者懂产品，知其然还要知其所以然。但是只是“像”，但不是，因为当你是工程师，太专业就不合适了。
在这里我总结了一下我个人的思考过程，您可以参考下。（当然，我个人是对产品和场景的了解是比较充足的，这个理解的过程只是针对新功能、新场景。如果你不够了解行业和产品的整体概况，需要提前准备一下）
这个图并不标准，每个人思考的过程存在差异，仅供参考。
私以为，针对产品的输出，主要包括三个阶段：了解-思考-输出。
- “了解”阶段主要是选取尽量多的角度，去观察产品。不仅要明白我们的产品如何设计，也要知道竞品的设计。看到尽量多的细节，才能够在思考阶段取得更深入的进展。
- “思考”阶段，产品设计是正向的过程，根据场景得到功能，而其他人对产品的理解都是“逆向”的，根据功能反推产品经理的设计思路。这个阶段要多于产品经理交流，既可以帮助他对功能进行复盘，也可以保证自己的理解不会出现偏差。
- “输出”阶段，我一直信奉“文不如表，表不如图”，简洁明了的流程图／示意图／泳道图都是极佳的表达形式。如果实在画不出，那么试图通过表格对内容进行整理概括也不错。
善用图表
在输出阶段，我们要足够善用图表。
例如：一个敏捷开发的场景，在Worktile7.0中的搭建，用图来表示是非常简洁的。这些内容用文字，恐怕至少要写够800字。
同时，图可以表达很多文字不能清晰描述的东西，尤其是产品的设计过程中存在大量的逻辑关系。例如下图可以清晰的表述一个任务的状态流转关系，如果用文字表述，那会是一件十分费力不讨好的事情了。
必要的时候可以插入产品的截图，但是量一定要少，关键截图有一两张就够了。太多的话，就会看起来像一本说明书。
拒绝主观色彩和形容词
大量的主观色彩，会让原本充满理性和说服力的文章变成“一家之言”；而主观色彩的一个表现，就是大量的形容词。
“方便”“简单”“强大”之类的价值，是作者想要达到的目标。但是这些词大量的出现在文章中时，就会显得空洞且丝毫不具备说服力。
比如：Worktile7.0配置功能强大，前台操作简单快捷，适配多种场景，能够帮助企业有效提高办公管理效率。
用我上文提到的标准，换成竞品也毫无违和感。产品介绍的文章，旨在把产品讲清楚，不卑不亢，不褒不贬是最好的感觉。
不可陷入用户场景
不知从何时开始，场景化的描述越来越普遍。不信你打开SaaS产品的官网，十有六七是列举了所谓的“痛点”然后引出产品介绍。
一般这样的描述有两个问题：
- 痛点只是“所谓”的痛点，实际上场景和问题千变万化，如果这几点戳不中用户，这篇文章的价值就没了。
- 很多描述缺乏痛点和产品之间的联系。我之前在某个官网上看到解决方案的下载，要求选择“行业”和“规模”这个维度。当我全部下载下来之后，发现其实只有四个模板。也就是针对很多行业和规模，他们提供的解决方案并没有任何一点区别。然而，10人、100人和1000人怎么可能一样呢？这个内容的质量也就不言而喻了。
所以归结到底，产品介绍本身还是应该围绕产品而来的。场景描述只是引子，不能陷进去。因为你的文章篇幅有限，无论如何也不可能概括50%的场景，针对产品特性和功能的描述才是主体。