1. 从一个被问烂的问题说起简介和功能到底该怎么写做产品、做开源项目、做内部工具甚至写一份个人作品集绕不开的第一道坎就是“简介和功能”。我见过太多人在这上面栽跟头功能列表洋洋洒洒写了两屏用户看完不知道这东西是干嘛的或者简介写得云山雾罩技术圈的人觉得太虚非技术的人觉得太玄。更常见的是把“简介”和“功能”当成两件互不相干的事简介归简介功能归功能中间没有任何逻辑咬合。这个项目标题看起来朴素得不能再朴素但它背后藏着一个非常具体的能力用最短的路径让目标读者在三十秒内建立准确预期并且愿意继续往下看。它适合所有需要对外表达“我做了个什么东西”的人——独立开发者、产品经理、技术博主、开源维护者、甚至是在团队内部做技术分享的工程师。你不需要是文案高手但你需要一套可复用的结构。我自己的经验是简介和功能不是“写”出来的是“拆”出来的。你得先想清楚三件事这东西解决谁的什么问题、它凭什么能解决、它跟同类东西比凭什么值得多看一眼。这三件事想明白了简介就是一句话的事功能就是这句话的展开论证。接下来我会把这套拆解逻辑完整摊开包括我踩过的坑、试过的模板、以及最终沉淀下来的实操方法。2. 简介和功能的底层逻辑先做减法再做加法2.1 为什么大多数人写反了顺序绝大多数人写简介和功能的顺序是先罗列功能再憋一句简介。这个顺序是反的。你一旦先列功能就会陷入“我做了什么”的视角而不是“用户得到什么”的视角。比如你做了一个支持多端同步的笔记工具先列功能就会写成“支持Markdown、支持标签、支持全文搜索、支持云同步”用户看完没有任何感觉因为这些都是功能名词不是价值动词。正确的顺序是先定一句话简介再让每个功能去证明这句话。简介是论点功能是论据。论据不能脱离论点存在否则就是一堆散装事实。我试过很多次先写简介再写功能功能列表会自动收敛因为你会不自觉地删掉那些跟简介无关的条目。这个减法过程极其重要它决定了你的表达是锋利还是臃肿。2.2 一句话简介的三种可靠结构简介不是越短越好而是越准越好。我常用的有三种结构分别对应不同的场景。第一种是“为谁解决什么”结构适合工具类产品。句式是为[目标人群]解决[具体问题]的[产品形态]。比如“为独立开发者解决API调试效率问题的桌面客户端”。这个结构的好处是人群和问题都具体读者能立刻判断自己是不是目标用户。第二种是“不同于什么”结构适合竞争激烈的领域。句式是不是[常见方案]而是[差异化方案]。比如“不是又一个待办清单而是把任务拆解到分钟级的执行系统”。这个结构直接建立对比锚点让读者知道你的定位。第三种是“从A到B”结构适合流程改造类工具。句式是把[旧流程]变成[新流程]。比如“把散落在聊天记录里的需求变成可追踪的结构化任务”。这个结构强调变化适合有明确前后对比的场景。三种结构可以组合使用但一句话简介里最多用两种否则会显得拥挤。我一般会写五六个版本然后挑一个读起来最不费劲的。2.3 功能列表的筛选标准三个问题淘汰法功能列表最容易犯的错是“有什么写什么”。我给自己定了一个硬标准每个功能必须能回答三个问题中的至少两个否则删掉。第一个问题这个功能是否直接支撑简介里的核心承诺如果不支撑哪怕它很酷也不应该出现在主功能列表里。它可以放在“其他特性”或者“路线图”里但不能占用主列表的位置。第二个问题这个功能是否可被验证或体验如果用户看完不知道怎么做才能感受到这个功能那它就是一句空话。比如“极速同步”不如“增量同步1000条笔记首次同步不超过3秒”来得实在。第三个问题这个功能是否与同类产品形成差异如果所有同类产品都有这个功能那它就不应该被重点展示。它可以是基础能力但不应该是卖点。三个问题过一遍通常能砍掉一半以上的功能条目。剩下的才是真正值得写的。3. 简介和功能的实操写法从草稿到定稿的完整流程3.1 第一步建立“问题-方案-证据”三栏表在动笔之前我会先拉一个三栏表。左边写目标用户遇到的具体问题中间写我的方案是什么右边写我能拿出的证据。这个表不需要给别人看但它能逼我把逻辑理顺。用户问题方案证据不知道每天时间花在哪自动时间追踪无需手动计时后台记录应用使用时长记录太麻烦坚持不下来一键开始/结束平均记录一条不超过2秒数据散落无法复盘周报自动生成每周一早上推送上周时间分布这个表填完简介和功能其实已经呼之欲出了。简介就是“为谁解决什么”的提炼功能就是中间那一列的展开证据就是每个功能后面的具体说明。3.2 第二步写简介的“三稿法”第一稿叫“说人话稿”。不考虑任何修辞就用最直白的话把这件事说清楚。比如“这是一个帮你记录时间花在哪的工具”。这一稿通常很土但它保证了信息完整。第二稿叫“加限定稿”。在第一稿基础上加上人群和场景限定。比如“这是一个帮自由职业者记录时间花在哪、并且自动生成周报的工具”。这一稿开始有针对性了。第三稿叫“去废话稿”。把第二稿里所有可以删掉的字删掉。比如“帮自由职业者记录时间并自动生成周报的工具”。这一稿就是最终简介的雏形。三稿下来简介通常能控制在20到40个字之间。超过40个字说明你还没想清楚核心是什么。3.3 第三步功能描述的“动词优先”原则功能描述最常见的毛病是名词堆砌。比如“多端同步、标签管理、全文搜索”全是名词读者感受不到动作。我强制自己用动词开头并且尽量用具体动词。对比一下名词版多端同步动词版在手机和电脑之间自动同步改完即存名词版标签管理动词版给每条记录打标签按标签筛选只要点一下名词版全文搜索动词版输入任意关键词一秒内定位到相关记录动词优先的好处是读者会自动在脑子里模拟使用场景。模拟得越顺畅转化率越高。这个原则我用了三年几乎每次都能让功能列表的可读性提升一个档次。3.4 第四步用“如果只能留三个”做压力测试功能列表写完之后我会做一个压力测试如果只能留三个功能留哪三个这三个功能必须能独立支撑起简介的承诺。如果留不下来三个说明简介写大了需要收窄。如果三个功能之间有重叠说明功能划分不够独立。这个测试还有一个变体如果用户只看功能列表不看简介能不能猜出这个产品是干嘛的如果猜不出来说明功能列表和简介脱节了需要重新对齐。4. 不同场景下的简介和功能写法差异4.1 开源项目简介要“可搜索”功能要“可验证”开源项目的简介和功能跟商业产品不太一样。商业产品可以讲情怀开源项目必须讲清楚“这东西能跑起来吗、怎么跑、跑起来能干嘛”。简介里最好包含技术栈关键词因为很多人是通过搜索“Python 时间追踪”这样的词找到项目的。功能列表要尽量可验证。比如“支持SQLite存储”比“数据安全可靠”更可信因为前者可以去看代码后者只能听你说。我维护过一个开源小工具把功能列表从“高性能、易扩展、跨平台”改成“单文件无依赖、启动时间小于100毫秒、支持Windows/macOS/Linux”Star数在两周内翻了一倍。不是功能变了是表达方式变了。4.2 内部工具简介要“省时间”功能要“省步骤”内部工具的读者是你的同事他们不关心技术多牛只关心“这东西能不能让我少干点活”。简介要直接说省什么时间比如“把每周手动填报表的时间从两小时压到十分钟”。功能列表要写清楚具体省了哪些步骤比如“自动从Jira拉取本周完成任务不需要手动复制粘贴”。内部工具的功能列表还有一个特殊要求要写清楚“不做什么”。因为同事会默认你能做所有事提前划清边界能减少很多沟通成本。比如“不包含审批流审批仍在OA系统完成”。4.3 个人作品集简介要“有观点”功能要“有细节”个人作品集的简介和功能本质是在回答“你为什么值得被记住”。简介要有观点不能只是“我做了个XX”。比如“我做了个把会议录音自动变成行动项的工具因为我觉得开会最浪费时间的不是开是开完没人记得要干嘛”。这个观点本身就是筛选器认同的人会继续看不认同的人早点离开对双方都好。功能列表要写细节尤其是那些“只有做过的人才知道的细节”。比如“录音转文字用了本地模型因为会议内容涉及内部信息不能上传到第三方”。这种细节比“注重隐私”有力一百倍。5. 常见问题与排查技巧实录5.1 简介写得太虚怎么办虚的根源是形容词太多。把简介里所有形容词圈出来逐个问这个词能不能换成数字、场景或者对比比如“高效”换成“三秒内完成”“强大”换成“支持同时处理1000条记录”“友好”换成“不需要看文档就能上手”。换完还虚说明你对目标用户的理解还不够具体需要回去补用户调研。5.2 功能列表太长怎么办先按“三个问题淘汰法”砍一遍。砍完还长就做分组。把功能分成“核心功能”和“辅助功能”核心功能不超过五个辅助功能用一句话带过。如果辅助功能也很多说明产品定位不清晰需要重新想简介。5.3 简介和功能对不上怎么办这是最常见的问题。简介说“为设计师解决素材管理问题”功能列表里却有一半是“支持团队协作”。对不上的部分要么删掉要么改简介。我的经验是改简介比删功能更常见因为功能往往是真实存在的而简介一开始写窄了。5.4 不同渠道的简介要不要统一要统一核心信息但可以调整长度和语气。官网首页可以用完整版简介应用商店可以用短版社交媒体可以用更口语化的版本。但核心承诺必须一致否则用户从不同渠道进来会感到困惑。常见问题排查思路解决方法简介太虚圈出所有形容词换成数字、场景或对比功能太长三个问题淘汰法砍掉不支撑简介的条目简介功能脱节只看功能猜产品对齐或收窄简介渠道信息不一致对比各渠道核心承诺统一核心调整表达5.5 一个容易被忽略的细节功能顺序功能列表的顺序不是随意的。第一个功能应该是最能支撑简介的那个第二个应该是使用频率最高的那个第三个应该是差异化的那个。这个顺序符合读者的阅读心理先确认价值再确认常用最后确认独特。我见过很多产品把最酷但最低频的功能放在第一位结果用户看完觉得“酷但用不上”直接关掉页面。6. 我自己的实操心得与避坑清单6.1 先写简介再写功能不要反过来这个顺序我强调多少次都不为过。先写功能会让你陷入“我做了什么”的泥潭先写简介会让你保持“用户得到什么”的清醒。我试过先写功能再憋简介结果简介怎么写都像在给功能列表打补丁。反过来之后功能列表会自动瘦身。6.2 找三个目标用户读一遍只问一个问题写完简介和功能之后找三个目标用户读一遍只问一个问题“你觉得这东西是干嘛的”如果三个人说的不一样说明简介失败了。如果三个人说的跟你预期的不一样说明简介和功能脱节了。如果三个人说的跟你预期一样但没人表示想用说明功能列表没有打动他们需要加强证据。6.3 简介里不要出现“一站式”“全方位”“极致”这类词这些词已经被用烂了读者看到会自动跳过。它们不传递任何信息只传递“我想显得很厉害”。把“一站式时间管理”换成“记录、统计、复盘都在一个地方”信息量立刻不一样。6.4 功能描述里不要用“支持”开头“支持多端同步”不如“在手机和电脑之间自动同步”。“支持”是一个没有画面的动词读者感受不到动作。换成具体动作之后读者会在脑子里模拟使用场景模拟越顺畅越有可能真的去用。6.5 留一个“不做什么”的说明不管是开源项目还是内部工具我都会在功能列表最后加一句“目前不做什么”。比如“目前不支持多人实时协作协作仍在聊天工具里完成”。这句话能减少很多无效提问也能让读者觉得你诚实。诚实本身就是一种差异化。6.6 定期重写不要一次定终身简介和功能不是写一次就完事的。产品在变用户在变竞争环境也在变。我一般每三个月重写一次简介和功能哪怕产品没有大改。重写的过程会逼我重新思考“这东西到底为谁解决什么问题”很多时候会发现自己已经偏离了最初的方向。6.7 一个私藏技巧用“电梯测试”做最终检验电梯测试的经典版本是你能不能在电梯从一楼到十楼的时间里把简介和功能说清楚。我的版本更狠一点你能不能让一个完全不懂你领域的人在听完之后用自己的话复述一遍。如果复述得八九不离十说明你的简介和功能已经足够清晰了。如果复述得乱七八糟回去改别犹豫。这个项目标题看起来简单但真正做好的人不多。我见过太多产品死在“说不清楚自己是什么”上不是东西不好是表达没跟上。简介和功能是产品和用户之间的第一座桥桥搭得稳不稳直接决定了用户愿不愿意走过来。我自己的经验是把简介和功能当成一个持续迭代的产品来做而不是一次性的文案任务效果会好很多。每次重写都是一次重新理解用户的机会别浪费。
简介和功能怎么写：从底层逻辑到实操的完整指南
1. 从一个被问烂的问题说起简介和功能到底该怎么写做产品、做开源项目、做内部工具甚至写一份个人作品集绕不开的第一道坎就是“简介和功能”。我见过太多人在这上面栽跟头功能列表洋洋洒洒写了两屏用户看完不知道这东西是干嘛的或者简介写得云山雾罩技术圈的人觉得太虚非技术的人觉得太玄。更常见的是把“简介”和“功能”当成两件互不相干的事简介归简介功能归功能中间没有任何逻辑咬合。这个项目标题看起来朴素得不能再朴素但它背后藏着一个非常具体的能力用最短的路径让目标读者在三十秒内建立准确预期并且愿意继续往下看。它适合所有需要对外表达“我做了个什么东西”的人——独立开发者、产品经理、技术博主、开源维护者、甚至是在团队内部做技术分享的工程师。你不需要是文案高手但你需要一套可复用的结构。我自己的经验是简介和功能不是“写”出来的是“拆”出来的。你得先想清楚三件事这东西解决谁的什么问题、它凭什么能解决、它跟同类东西比凭什么值得多看一眼。这三件事想明白了简介就是一句话的事功能就是这句话的展开论证。接下来我会把这套拆解逻辑完整摊开包括我踩过的坑、试过的模板、以及最终沉淀下来的实操方法。2. 简介和功能的底层逻辑先做减法再做加法2.1 为什么大多数人写反了顺序绝大多数人写简介和功能的顺序是先罗列功能再憋一句简介。这个顺序是反的。你一旦先列功能就会陷入“我做了什么”的视角而不是“用户得到什么”的视角。比如你做了一个支持多端同步的笔记工具先列功能就会写成“支持Markdown、支持标签、支持全文搜索、支持云同步”用户看完没有任何感觉因为这些都是功能名词不是价值动词。正确的顺序是先定一句话简介再让每个功能去证明这句话。简介是论点功能是论据。论据不能脱离论点存在否则就是一堆散装事实。我试过很多次先写简介再写功能功能列表会自动收敛因为你会不自觉地删掉那些跟简介无关的条目。这个减法过程极其重要它决定了你的表达是锋利还是臃肿。2.2 一句话简介的三种可靠结构简介不是越短越好而是越准越好。我常用的有三种结构分别对应不同的场景。第一种是“为谁解决什么”结构适合工具类产品。句式是为[目标人群]解决[具体问题]的[产品形态]。比如“为独立开发者解决API调试效率问题的桌面客户端”。这个结构的好处是人群和问题都具体读者能立刻判断自己是不是目标用户。第二种是“不同于什么”结构适合竞争激烈的领域。句式是不是[常见方案]而是[差异化方案]。比如“不是又一个待办清单而是把任务拆解到分钟级的执行系统”。这个结构直接建立对比锚点让读者知道你的定位。第三种是“从A到B”结构适合流程改造类工具。句式是把[旧流程]变成[新流程]。比如“把散落在聊天记录里的需求变成可追踪的结构化任务”。这个结构强调变化适合有明确前后对比的场景。三种结构可以组合使用但一句话简介里最多用两种否则会显得拥挤。我一般会写五六个版本然后挑一个读起来最不费劲的。2.3 功能列表的筛选标准三个问题淘汰法功能列表最容易犯的错是“有什么写什么”。我给自己定了一个硬标准每个功能必须能回答三个问题中的至少两个否则删掉。第一个问题这个功能是否直接支撑简介里的核心承诺如果不支撑哪怕它很酷也不应该出现在主功能列表里。它可以放在“其他特性”或者“路线图”里但不能占用主列表的位置。第二个问题这个功能是否可被验证或体验如果用户看完不知道怎么做才能感受到这个功能那它就是一句空话。比如“极速同步”不如“增量同步1000条笔记首次同步不超过3秒”来得实在。第三个问题这个功能是否与同类产品形成差异如果所有同类产品都有这个功能那它就不应该被重点展示。它可以是基础能力但不应该是卖点。三个问题过一遍通常能砍掉一半以上的功能条目。剩下的才是真正值得写的。3. 简介和功能的实操写法从草稿到定稿的完整流程3.1 第一步建立“问题-方案-证据”三栏表在动笔之前我会先拉一个三栏表。左边写目标用户遇到的具体问题中间写我的方案是什么右边写我能拿出的证据。这个表不需要给别人看但它能逼我把逻辑理顺。用户问题方案证据不知道每天时间花在哪自动时间追踪无需手动计时后台记录应用使用时长记录太麻烦坚持不下来一键开始/结束平均记录一条不超过2秒数据散落无法复盘周报自动生成每周一早上推送上周时间分布这个表填完简介和功能其实已经呼之欲出了。简介就是“为谁解决什么”的提炼功能就是中间那一列的展开证据就是每个功能后面的具体说明。3.2 第二步写简介的“三稿法”第一稿叫“说人话稿”。不考虑任何修辞就用最直白的话把这件事说清楚。比如“这是一个帮你记录时间花在哪的工具”。这一稿通常很土但它保证了信息完整。第二稿叫“加限定稿”。在第一稿基础上加上人群和场景限定。比如“这是一个帮自由职业者记录时间花在哪、并且自动生成周报的工具”。这一稿开始有针对性了。第三稿叫“去废话稿”。把第二稿里所有可以删掉的字删掉。比如“帮自由职业者记录时间并自动生成周报的工具”。这一稿就是最终简介的雏形。三稿下来简介通常能控制在20到40个字之间。超过40个字说明你还没想清楚核心是什么。3.3 第三步功能描述的“动词优先”原则功能描述最常见的毛病是名词堆砌。比如“多端同步、标签管理、全文搜索”全是名词读者感受不到动作。我强制自己用动词开头并且尽量用具体动词。对比一下名词版多端同步动词版在手机和电脑之间自动同步改完即存名词版标签管理动词版给每条记录打标签按标签筛选只要点一下名词版全文搜索动词版输入任意关键词一秒内定位到相关记录动词优先的好处是读者会自动在脑子里模拟使用场景。模拟得越顺畅转化率越高。这个原则我用了三年几乎每次都能让功能列表的可读性提升一个档次。3.4 第四步用“如果只能留三个”做压力测试功能列表写完之后我会做一个压力测试如果只能留三个功能留哪三个这三个功能必须能独立支撑起简介的承诺。如果留不下来三个说明简介写大了需要收窄。如果三个功能之间有重叠说明功能划分不够独立。这个测试还有一个变体如果用户只看功能列表不看简介能不能猜出这个产品是干嘛的如果猜不出来说明功能列表和简介脱节了需要重新对齐。4. 不同场景下的简介和功能写法差异4.1 开源项目简介要“可搜索”功能要“可验证”开源项目的简介和功能跟商业产品不太一样。商业产品可以讲情怀开源项目必须讲清楚“这东西能跑起来吗、怎么跑、跑起来能干嘛”。简介里最好包含技术栈关键词因为很多人是通过搜索“Python 时间追踪”这样的词找到项目的。功能列表要尽量可验证。比如“支持SQLite存储”比“数据安全可靠”更可信因为前者可以去看代码后者只能听你说。我维护过一个开源小工具把功能列表从“高性能、易扩展、跨平台”改成“单文件无依赖、启动时间小于100毫秒、支持Windows/macOS/Linux”Star数在两周内翻了一倍。不是功能变了是表达方式变了。4.2 内部工具简介要“省时间”功能要“省步骤”内部工具的读者是你的同事他们不关心技术多牛只关心“这东西能不能让我少干点活”。简介要直接说省什么时间比如“把每周手动填报表的时间从两小时压到十分钟”。功能列表要写清楚具体省了哪些步骤比如“自动从Jira拉取本周完成任务不需要手动复制粘贴”。内部工具的功能列表还有一个特殊要求要写清楚“不做什么”。因为同事会默认你能做所有事提前划清边界能减少很多沟通成本。比如“不包含审批流审批仍在OA系统完成”。4.3 个人作品集简介要“有观点”功能要“有细节”个人作品集的简介和功能本质是在回答“你为什么值得被记住”。简介要有观点不能只是“我做了个XX”。比如“我做了个把会议录音自动变成行动项的工具因为我觉得开会最浪费时间的不是开是开完没人记得要干嘛”。这个观点本身就是筛选器认同的人会继续看不认同的人早点离开对双方都好。功能列表要写细节尤其是那些“只有做过的人才知道的细节”。比如“录音转文字用了本地模型因为会议内容涉及内部信息不能上传到第三方”。这种细节比“注重隐私”有力一百倍。5. 常见问题与排查技巧实录5.1 简介写得太虚怎么办虚的根源是形容词太多。把简介里所有形容词圈出来逐个问这个词能不能换成数字、场景或者对比比如“高效”换成“三秒内完成”“强大”换成“支持同时处理1000条记录”“友好”换成“不需要看文档就能上手”。换完还虚说明你对目标用户的理解还不够具体需要回去补用户调研。5.2 功能列表太长怎么办先按“三个问题淘汰法”砍一遍。砍完还长就做分组。把功能分成“核心功能”和“辅助功能”核心功能不超过五个辅助功能用一句话带过。如果辅助功能也很多说明产品定位不清晰需要重新想简介。5.3 简介和功能对不上怎么办这是最常见的问题。简介说“为设计师解决素材管理问题”功能列表里却有一半是“支持团队协作”。对不上的部分要么删掉要么改简介。我的经验是改简介比删功能更常见因为功能往往是真实存在的而简介一开始写窄了。5.4 不同渠道的简介要不要统一要统一核心信息但可以调整长度和语气。官网首页可以用完整版简介应用商店可以用短版社交媒体可以用更口语化的版本。但核心承诺必须一致否则用户从不同渠道进来会感到困惑。常见问题排查思路解决方法简介太虚圈出所有形容词换成数字、场景或对比功能太长三个问题淘汰法砍掉不支撑简介的条目简介功能脱节只看功能猜产品对齐或收窄简介渠道信息不一致对比各渠道核心承诺统一核心调整表达5.5 一个容易被忽略的细节功能顺序功能列表的顺序不是随意的。第一个功能应该是最能支撑简介的那个第二个应该是使用频率最高的那个第三个应该是差异化的那个。这个顺序符合读者的阅读心理先确认价值再确认常用最后确认独特。我见过很多产品把最酷但最低频的功能放在第一位结果用户看完觉得“酷但用不上”直接关掉页面。6. 我自己的实操心得与避坑清单6.1 先写简介再写功能不要反过来这个顺序我强调多少次都不为过。先写功能会让你陷入“我做了什么”的泥潭先写简介会让你保持“用户得到什么”的清醒。我试过先写功能再憋简介结果简介怎么写都像在给功能列表打补丁。反过来之后功能列表会自动瘦身。6.2 找三个目标用户读一遍只问一个问题写完简介和功能之后找三个目标用户读一遍只问一个问题“你觉得这东西是干嘛的”如果三个人说的不一样说明简介失败了。如果三个人说的跟你预期的不一样说明简介和功能脱节了。如果三个人说的跟你预期一样但没人表示想用说明功能列表没有打动他们需要加强证据。6.3 简介里不要出现“一站式”“全方位”“极致”这类词这些词已经被用烂了读者看到会自动跳过。它们不传递任何信息只传递“我想显得很厉害”。把“一站式时间管理”换成“记录、统计、复盘都在一个地方”信息量立刻不一样。6.4 功能描述里不要用“支持”开头“支持多端同步”不如“在手机和电脑之间自动同步”。“支持”是一个没有画面的动词读者感受不到动作。换成具体动作之后读者会在脑子里模拟使用场景模拟越顺畅越有可能真的去用。6.5 留一个“不做什么”的说明不管是开源项目还是内部工具我都会在功能列表最后加一句“目前不做什么”。比如“目前不支持多人实时协作协作仍在聊天工具里完成”。这句话能减少很多无效提问也能让读者觉得你诚实。诚实本身就是一种差异化。6.6 定期重写不要一次定终身简介和功能不是写一次就完事的。产品在变用户在变竞争环境也在变。我一般每三个月重写一次简介和功能哪怕产品没有大改。重写的过程会逼我重新思考“这东西到底为谁解决什么问题”很多时候会发现自己已经偏离了最初的方向。6.7 一个私藏技巧用“电梯测试”做最终检验电梯测试的经典版本是你能不能在电梯从一楼到十楼的时间里把简介和功能说清楚。我的版本更狠一点你能不能让一个完全不懂你领域的人在听完之后用自己的话复述一遍。如果复述得八九不离十说明你的简介和功能已经足够清晰了。如果复述得乱七八糟回去改别犹豫。这个项目标题看起来简单但真正做好的人不多。我见过太多产品死在“说不清楚自己是什么”上不是东西不好是表达没跟上。简介和功能是产品和用户之间的第一座桥桥搭得稳不稳直接决定了用户愿不愿意走过来。我自己的经验是把简介和功能当成一个持续迭代的产品来做而不是一次性的文案任务效果会好很多。每次重写都是一次重新理解用户的机会别浪费。
