主要思路：

1、明确需求细节

2、分析需求，给出产品初步建议

3、确定目标，达成共识

4、持续跟进，及时反馈

一、明确需求细节

跨部门的需求指的是其他部门提交来的需求，有时候是反馈某个APP的问题，有时候是建议，有时候是有个活动需要技术支持，五花八门。

这个时候产品经理要做的事情就是多追问几个为什么，进一步了解这个需求的其他信息。

比如说：

明确主体：这个需求是你自己希望有的吗？还是转述用户的？多少人也有这个需求？

明确强度：为什么想要实现这个需求？最希望解决什么问题？你对它的期望是怎么样的？这个需求对你（提出人来说）有多急迫？希望什么时候解决（上线）？不解决会有什么影响？现在你是怎么解决的？为什么？你现在的解决方案里你最不满的是什么？

明确频率和持续时间：你一般什么时候会有这个需求？是临时的还是以后会固定做？每次用多久？3天，还是30天？

其他信息：具体需要我们支持什么？设计？页面？有没有参考的案例？截图？链接？原型？

这些只是参考问题，实际上可以根据需求的复杂程度增减。总之，这个环节要多聊，引导出需求者真正想要的

二、分析需求，给出产品初步建议

了解完需求之后，得出一个判断：目标用户有没有这个需求？即使是运营或者市场活动，最后也要归集到用户原始需求这个维度。如果大部分用户真的有这个需求，那就值得做。

接着针对获取到的所有信息进行综合分析。有三个因素需要考虑，这个需求值不值得做：

1、我们的目标用户真的有这个需求吗？我们真的有必要做这个功能吗？

有时候我们以为用户需要的，未必是他们真正想要的。

2、这个需求跟我们的公司战略，产品定位，运营目标一致吗？

如果是部门需求：考虑的是这个需求对我们的主营业务有多少关系？会带来多少价值？这个价值是可控的吗？可衡量的吗?然后从他们工作的考虑，这个功能会有多少帮助？提升多少效率？

如果是用户需求：尤其要考虑的是，这个新需求是否符合之前的产品总体架构。大原则是如果没有必要，尽量不加功能。尽可能在原有功能的基础上实现。没有完全考虑清楚的需求，实在要做的，先少做，简单做。先试再看看反馈后调整。

3、这个需求从技术上评估投入产出比，给出需求处理结果

通过前面几步确定产品方案，确定出需要支持的事项清单，时间要求。然后技术评估实现成本。

评估成本需要考虑是否可实现，需要多少工时实现，需要多少设计，按照功能和清单单项估算出整个需求要实现需要的总时间。权衡下。

这个环节，会确定出需求的处理结果。

不做，为什么？

做，现在做还是以后做?

三、确定目标，达成共识

把产品分析结果，产品方案，需要支持的清单，技术评估成果跟需求提出人沟通。

然后进一步确认目标。

针对这个需求最希望达成的目标是什么？

这个初步的产品方案是不是能够达成？

我们下一步要做什么准备？谁来具体负责，跟进？什么时候进入测试？什么时候正式使用

细化需求，形成方案，任务清单，项目进度表。

明确为了满足这个需求，我们负责什么，对接人负责什么，接下来要做什么。

四、持续跟进，及时反馈

根据不同的处理结果及时给反馈。给对接的同事安全感和确定感。

BUG，好改的马上就改了。不好改的，进入需求池等待安排。

改进，好实现的马上就实现了。需要发版的，下版本一起解决。不好改的进入需求池等待安排。

项目，按照重要紧急程度，给出项目进度表持续跟进。过程中的问题随时反馈。

以上就是目前想到的~~