产品经理技能写法指南 产品经理专业技能怎么写

首先,产品经理需要输出的主要文档有:信息结构图(供产品经理自己整理信息,与开发人员讨论数据结构)和产品结构图 。
(供产品团队内部更清晰的管理产品的功能),原型图(线框图,产品宣讲时用到,设计,技术,老板更明确理解产品意图),产品需求文档(最终执行文档,针对开发,设计人员) 。以下将对这些文档的意义以及使用到的制作工具,进行说明 。
产品需求文档(PRD)产品设计的最终表述称为产品需求文档,业内常称之为PRD文档,是英文Product Requirement Document的缩写 。PRD文件是基于BRD和MRD的延续文件 。主要是给高管层的工作人员看的文档,这些人大多是设计师和技术人员 。在这个人群中,设计师更依赖产品原型进行交互或视觉设计,所以看这份文档的人主要是技术人员 。相对于技术人员来说,他们并不太关注产品的商业需求和市场眼光,因为产品的定义早在讨论立项的时候就已经向参与设计和R&D的人员宣讲过了 。所以技术人员更注重界面、功能、交互、元素等等,所以产品需求文档是产品功能需求的详细描述文档,是产品文档中最底层也是最详细的文档 。主要介绍功能描述 。目的是一样的,产品的功能需求一定要明确,让执行人员明白任务需求 。—策划和设计后产品的最终执行文件 。
1 。列表信息(信息结构图)
在写产品需求文档之前,我们应该先列出产品功能的信息内容 。这一步是逐步理清思路的第一步,也是帮助我们接下来设计功能的辅助信息 。同时,它还可以帮助服务器技术人员创建数据库 。因为这是第一步,所以不需要详细列举 。在接下来的步骤中,我们将逐步改进和完善信息内容 。
列出信息内容的方式有很多种,比如文本形式、思维导图形式等等 。最重要的是要清晰易懂 。最常用的方法我用MindManager把它列成一个结构图,所以我把这个步骤叫做“信息结构图” 。
image.png
上图是以博客系统为例的信息结构图 。信息图是接近数据库结构的图 。在列举信息结构时,更多关注的是信息数据,而不是真正的数据库结构 。信息图是提供给产品经理自己整理信息内容的结构图,也是方便产品经理与服务器端技术人员沟通数据结构的参考图 。技术人员会根据这个图的内容,结合产品原型或者需求文档,规划设计真正的数据库结构 。
信息图中关于友情链接功能的信息数据只有两个内容:名称和链接 。但是,在实际的功能需求中,友情链接有两个功能,即显示或隐藏和打开新窗口 。这两个功能在产品原型和需求文档中会有详细描述,但在信息结构中没有体现,因为从产品层面来说,这两个功能只是功能,不是信息内容 。但是在真实的数据库中,友情链接的这两个函数也分别有字段参数 。程序读取这个参数后,就会知道友情链接的属性,然后处理友情链接是显示还是隐藏,是打开一个新窗口还是打开这个窗口 。通过友情链接的例子,我们知道在实践中,数据结构和信息结构是不一样的,信息结构只是产品层面的数据内容 。
无论是哪种产品类型,无论从哪里入手,都要先列出信息结构,因为信息结构图不仅是帮助技术人员创建数据库的图,也是帮助产品人员规划产品功能的参考 。只有了解信息或数据的结构,才能更好地设计产品 。信息图是我们构建概念思路的第一步,也是我们下一步的辅助文档 。同时,我们将在下一步中不断完善信息结构 。
2 。整理需求(产品结构图)
当我们知道了产品的信息结构后,我们就需要在脑海中整理产品需求,让我们的思路更加结构化,所以这一步就需要对产品需求进行梳理 。在设计产品原型之前,首先要列出产品的功能结构,包括频道、页面、模块、元素 。这一步还是用mindmanager像画楼盘的鸟瞰图一样把产品的结构画成结构图,所以我把这一步叫做“产品结构图” 。
产品结构图是以结构化的方式展示产品原型的图,结构内容与产品原型相同,从渠道到页面,再细化页面功能模块和元素 。所以,产品结构图是产品经理在设计原型之前整理思路的一种方式,而不是供其他工作人员查看的文档 。鸟瞰式的结构图可以让产品经理对产品结构一目了然,方便其思考 。
image.png
如上例所示,“活动百科”的产品结构是:产品->渠道->页面->页面元素->运营->元素我们换个角度来看例子,产品结构图其实是一个结构化的产品原型 。这样做的目的是为了梳理产品结构逻辑,让我们清楚的知道产品有多少个渠道,渠道下有没有子渠道或者有多少个页面,这些页面里有哪些功能模块,这些功能模块里有哪些元素 。“产品结构图”基于我们第一步的“信息结构图” 。有了这个结构图,我们可以从鸟瞰的角度来考虑和改进产品 。有问题的时候修改比原型和文档方便多了 。比如在后续的策划中,我们发现上传后的文章图片等附件不方便管理,可以在结构图中增加一个“附件管理”的通道 。如果使用产品结构图,添加和修改附件管理的功能会比原型工具更加方便和高效 。


推荐阅读