蜗牛派
而其中最复杂就是逻辑部分，需要能清晰表达你的想法和思路。
要知道，在需求评审结束后，开发会按照你的逻辑落地实施，测试也会按照它撰写用例。
因此，如何能让多方在认知上达成一致，不仅考验产品经理写作的能力，还包括用户视角的同理心。
接下来，以我设计的一个功能为例，阐述优化PRD中的逻辑内容的方法，希望能帮到你。
一、功能背景介绍
在系统「周期性任务」这个功能里，可选择3种方式的下发，分别是：
（1）每日，可选择 0:00 至 23:59；
（2）每周，可选择周一至周日，提交时间设置 5 天或 7 天；
（3）每月，可选择 1 号 至 28 号；
而目前系统仅支持「下周期」下发，举个例子：
今天是周日（4-19），设置任务开始时间是今天（4-19 0:00），任务结束时间是（5-19 23:59），选择每周的周五，提交时间 7 天。
按照已有逻辑，第一条任务会从下周五（4-24 0:00）派发，总共会有4条任务。
不知道你有没有发现，从今天（4-19）到下周五（4-24）这期间是存在空档的。
回归到对方实际的业务场景，其实是有足够时间完成任务并提交。
而这就是本周期的概念。
对此，我们需要将这个功能做成可配置，由用户自己选择下发时间。
二、优化前
按照我之前习惯，我会分类地将每个情况写出来，并附带一个例子进行说明。
从大类上来说，总共有4种情况，分别是每日、每周（5天）、每周（7天）、每月，最后的结果如图所示。
说实话，写完后我自己都不愿意再看一遍，更不用说开发了。
但在当时，我并没有意识到这个问题，总觉得自己已经分类写的明明白白了。
开发，应该看得懂。
但在结果上，确实打脸了。
就因为逻辑的问题，整个评审的流程延长了好几个小时，虽然说最后多方人员都理解了。
但也还是出现开发中多次询问确认的情况。
这件事的问题，主要出在我身上。
事后我去反思这件事，确实应该换一种更好的方式来表述。
最起码，自己是得愿意看第二遍的。
三、优化后
之后我也在思考，到底以哪种方式呈现能便于对方理解，就有了以下的产物。
其实，逻辑上都一样，只是表现形式上有区别。
都说要把用户当傻瓜，那开发同学不也是我们的用户吗？
产品经理需要用最低的认知成本，将自己的思路表达给对方，而方式不过是手段罢了。
写在最后
每一次的功能迭代，其实都有可以优化的地方。
重点在于你愿不愿花这个时间去探寻新方法，并将它实际去运用。
要知道，工作中最花费精力的就是反复沟通。
当一件事2遍说不清楚的时候，我们就需要警惕了。
找出其中的问题，定点把它解决掉，那么我们就能获得提升。
成长，是在一点一滴中取得的。
愿你我一同努力，一起进步~
