#后台产品100个总结
No 2 :写好需求后，应该跟需求方确认需求，才能让后续产品上线更丝滑？
在做后台需求的时候，很多时候，产品经理是设计好完整的需求，拿着需求图给需求方看，坐在旁边认真讲解一番，需求方连连点头。但是等产品上线，需求方却说，啊，这不是我想要的。其实，没有几个业务方能看懂在还没有上线时候的需求图片，因为当初需求文档的查看方的本身是技术同学，产品经理写的越详尽，对于需求方来讲，就更像天书一般，更不想认真查看。
那不做需求确认了吗？只是听着需求方在第一轮的给我们的描述，产品经理凭着自身的理解，那更容易出现偏差。
那作为产品经理，如何能高效的跟需求方，达成真正的未来大家脑海中的需求图的共识呢？其实只需要提供2个部分，一是链路图，二是需求简洁版本页面。
一、链路图（最好打印出来）
在需求沟通环节，我们已经通过问情境，理出了需求本身的出发点和想要去往的解决终点，我们需要把这个过程列出来，形成一个清晰简洁的链路图，沟通中曾经强调的重点、需要特殊处理的关键点，都可以通过链路图清晰的画出来。这样子在跟需求方沟通的时候，能快速代入回对应的场景。而且强烈建议打印出来，这一方面，可以训练自身对于链路不要写的过于冗长，尽量用简洁的路径去描述，另外方面，能让大家聊天更容易专注，鼠标疯狂滑动，也不利于沟通。在沟通中，也可以快速用笔记补全链路图的部分。
二、简洁版本的需求图
在设计需求的时候，产品经理的需求图写的细节详尽，是为了后续能减少与研发开发过程纯沟通的时间，但这不适用于跟需求方确认。在需求方的确认，只需要在未来需求呈现时候的整体主页面的样式即可，目的是简洁，有呈现的表格、图表、筛选项，让大家在脑海中对于需求的那个画面的想象，能通过这个简洁的页面，能有大模块的确认。
通过这两个内容，既可以达到需求确认的目的，也不会双方都觉得，这一次的沟通没有效果，省时省力。
下一期预告：如何能让研发同学，成为你的强力助攻。#产品设计 #中后台产品
No 2 :写好需求后，应该跟需求方确认需求，才能让后续产品上线更丝滑？
在做后台需求的时候，很多时候，产品经理是设计好完整的需求，拿着需求图给需求方看，坐在旁边认真讲解一番，需求方连连点头。但是等产品上线，需求方却说，啊，这不是我想要的。其实，没有几个业务方能看懂在还没有上线时候的需求图片，因为当初需求文档的查看方的本身是技术同学，产品经理写的越详尽，对于需求方来讲，就更像天书一般，更不想认真查看。
那不做需求确认了吗？只是听着需求方在第一轮的给我们的描述，产品经理凭着自身的理解，那更容易出现偏差。
那作为产品经理，如何能高效的跟需求方，达成真正的未来大家脑海中的需求图的共识呢？其实只需要提供2个部分，一是链路图，二是需求简洁版本页面。
一、链路图（最好打印出来）
在需求沟通环节，我们已经通过问情境，理出了需求本身的出发点和想要去往的解决终点，我们需要把这个过程列出来，形成一个清晰简洁的链路图，沟通中曾经强调的重点、需要特殊处理的关键点，都可以通过链路图清晰的画出来。这样子在跟需求方沟通的时候，能快速代入回对应的场景。而且强烈建议打印出来，这一方面，可以训练自身对于链路不要写的过于冗长，尽量用简洁的路径去描述，另外方面，能让大家聊天更容易专注，鼠标疯狂滑动，也不利于沟通。在沟通中，也可以快速用笔记补全链路图的部分。
二、简洁版本的需求图
在设计需求的时候，产品经理的需求图写的细节详尽，是为了后续能减少与研发开发过程纯沟通的时间，但这不适用于跟需求方确认。在需求方的确认，只需要在未来需求呈现时候的整体主页面的样式即可，目的是简洁，有呈现的表格、图表、筛选项，让大家在脑海中对于需求的那个画面的想象，能通过这个简洁的页面，能有大模块的确认。
通过这两个内容，既可以达到需求确认的目的，也不会双方都觉得，这一次的沟通没有效果，省时省力。
下一期预告：如何能让研发同学，成为你的强力助攻。#产品设计 #中后台产品
