产品新人,如何将《产品需求文档》撰写更深入(进阶篇)


一、简述

撰写结构开发思维,是在产品需求文档基础上,需进一步提升的核心基本功。而这个基本功,决定着能否输出高度模块化的产品需求文档。

但是,许多的新入行的产品新人,对产品需求文档认识,局限在:“套个模板、添加个前置、后置条件、流程图”等认知,便能输出一份严谨的产品需求文档。事实上,这些都只是些浮于表层的事物!对于模板“是否拥有前置条件、后置条件”这些模块结构,对于产生优质的产品需求文档,其实并不是核心的决定因素。

纠结于产品模板,会导致新人误入形式,远离本质。这种场景下,很难将产品需求文档撰写严谨,最终必然导致内容空泛。我们对产品需求文档最终达到的效果,进行TAG概括:

推理严谨

逻辑合理

描述细致

场景清晰

在进阶版篇章中,我们从产品需求文档模板的框架中跳出来,在高一层的维度中,从“方法论”的角度展示。

根据案例:产品需求文档A产品需求文档B,基于撰写结构开发思维,如何实现“严谨、合理、细致、清晰”效果,进行案例分析。

二、撰写结构

撰写结构,就是基于被撰写的产品功能模块,有规划的进行内容组织。且将组织的内容清晰的描述出来,而内容组织并不局限在使用某个产品需求文档的模板中,只需要拥有个人“方法”,将产品功能描绘清晰即可。但,它须坚持一些原则:

符合浏览对象浏览信息流的习惯,被组织的内容权重主次清晰,并起到引导作用。

内容组织紧凑,功能模块内容结构划分清晰,区分明显。

结构化的撰写方式,以结构化的形式展示数据流、业务流、页面布局逻辑。

严谨的是与否判断。

产品需求文档A
产品需求文档B

产品需求文档A,在描绘需求时,采用的是“功能名称-需求说明(内容描述)-原型图”形式作为撰写结构,进行文档撰写,描述不够深入导致整体较为空洞,体现在:

页面布局。缺乏1、2级层级关系,用户浏览信息时,缺乏主次。需要查看参与者个人进行信息区分,队内容层级筛选。

整体排序。排序不符合查看参与浏览信息方式,不能起到引导用户有节奏地进行产品功能内容传递。

模块结构。内容结构单一,在“需求说明”上,无法系统化地进行产品功能细节描写,页面的数据流、逻辑关系无法清晰的表达。

撰写结构。文档描述口语化严重,缺乏结构化语言,思维零碎,无法引导查看参与者思维进行文档价值传递。

基于上述原因,产品需求文档A,对于产品功能涉及的“字段、操作逻辑、数据流、排序规则….等,都无清晰的表达出来。

产品需求文档B,采用竖并列式的结构进行文档撰写,整体显的紧凑,内容丰富,主要体现在:

完整的文档模块

产品需求文档B,文档模块,围绕产品功能的数据流与逻辑关系展开搭建,框架模块较为清晰。从产品功能名称介入,从“用例图、前置条件、后置条件、功能概述”的角度,将产品功能大的框架明确。

产品框架的基础上,进行产品功能模块细化,绘制出:“字段列表、表单、操作、交互、算法模型….”,而描述的模块与结构化的思维,将产品功能主次区分开,将细节进一步深入描述。如进行产品功能规划:“从主业务流切入,将核心流程打通。”后台:逻辑业务流,前台:选购支付流(流程不通,转化率必然很低)。

规范的内容排序

严谨的功能模块结合内容主次排序,如何符合参与角色浏览文档的习惯,便显的非常重要。产品需求文档A,在文档排序上,使用:“功能名称-功能说明-原型图”,这种描述逻辑是:

查看参与者,需要先看需求说明,才进入查看原型图,这种查看文档的交互方式,是有问题。

对于文档传递信息而言,第一步是进行整体的产品功能概念的价值灌输,从原型图了解大体的逻辑与数据,让参与对象可以在功能上对整体模块进行了解。在这个基础上,才进入细节描述,这个过程中才结合原型图,逐渐将功能细节撰写排序。这样利于后续交接方与提出方、研发方,在查看文档时,最短的时间熟悉产品功能的大体逻辑。

产品需求文档B,在内容排序上,采用“功能名称-原型图-整体业务框-功能说明”,这种描述的逻辑是:

了解功能,了解答题的功能内容-了解整体业务框架-进入细节了解,这种查看文档的交互方式,符合上述方法论,并且从浅往深引导查看参与者由浅至深的深入了解文档整体内容。

严谨的细节撰写

在整体框架的基础上,撰写的更深入。一方面,需要对行业业务知识进行积累;另一方面,对于所把握的产品功能的使用业务场景理解透彻。

在产品需求文档A中,每个字段、操作逻辑、判断条件、业务场景无严谨的说明,所描绘的内容仅局限于不清晰的页面布局与不清晰的提取数据记录。而产品需求文档B,采用格式化的形式进行文档撰写,在格式化的框架下,细致页面布局的字段与涉及业务场景、判断条件都能很好的进行描述。

而细节描述,尽量精确至每个字段。若所设计的字段与当前业务字段符合,请备注为当前功能不变,开发成熟的模块仅需要插进去。

但业务场景,必须想清晰,如:在某款特卖产品中,新增”浏览记录”功能点,常规用户进行历史浏览记录查看时,超过90%的浏览的记录时“无法进行购买超过”,这是影响用户体验,印象流量转化率。若后续在“本场景”下新增个性化推荐功能点,也显的有些不搭调,这个场景逻辑是:我看个人历史记录-没有了-推荐其它商品,那我干嘛还看我的历史浏览记录?若针对于活动热度这种特殊场景,但是浏览记录又是一个常规功能。而事实上,这是非常典型的没将功能点各个业务场景清晰的梳理清楚:

1、特卖商品拥有档期属性,若干天就需要对商品进行下架。

2、大量的用户非每天都会在本产品进行新商品浏览。(若是电商PM查看本文档,请查看贵平台后台的BI分析报表,查询一下日用户活跃度(DAU)的环比下降幅度,与用户平均查看商品数)

可理解的描述结构

产品需求文档A整体是缺乏结构的,而产品需求文档B是在结构化的框架下进行撰写。而描述结构围绕着产品功能或字段,围绕着“我是谁,我从那么来,我要那里去”,整体便非常清晰。

撰写结构,是产品需求文档非常核心的组成部份,在模块化、排序、细节、结构等层面上。一方面,从整体上解决产品需求文档A存在PRD撰写的问题。另一方面,将发散的思维收窄,聚焦至解决一个产品功能的业务问题上,包括字段数、业务逻辑、涉及的变量算法… ….清晰的描绘出来。

让PM把握产品功能整体,完整的的对价值实现上与下进行传递,并满足本章节提出的“撰写结构原则”条件。


三、开发思维

开发思维,是一种线性思维;在逻辑的世界里,只有“是与否”。是,则开始。否,则结束或进入下一个开始。

它们就像完美的整体,将产品从顶层战略至功能细节,体验在产品每个使用场景中(用户使用体验)(具体的用户体验,我们将从后续的篇章进行描述,这里不进行详细描写)。

正如在《倒爷教你写产品需求文档(基础篇)》中,计算机表达的是数据流与逻辑操作,那么开发思维,便是通过“是与否”,将产品细节,从数据流、操作逻辑关系的角度。描述出来;主要体现在两个方面:

数据流

在协助层与基础层之间,通过“数据控制”与“数据传送”两个动作,实现数据的仓储与传送。那么,前台主要是进行取值(数据提取),后台主要是数据发布与管理;而PM,需对所负责业务,对系统拥有哪些数据,与数据是如何控制拥有足够的把握。只要后台拥有产品功能模块数据,在不影响前台性能的前提下,在时间条件充足下,基本上可以实现。

随着平台业务的增长,平台需从开始由于“低门槛”让参与度提高的策略,摆脱前期策略导致的信息数据匮乏。后期需逐渐逐渐通过运营的手段,将前后台的业务数据补齐,支撑后期进行数据结构化分析,实现数据智能精准化运营。而数据流,必然少不了。

逻辑关系

机器的行为,是通过程序语言来实现。你需要输入某个指令,它才会去执行某个任务。在处理多个任务的时候,便需要对多个指令进行判断执行。而在前后台业务时,需要PM对每个业务状态场景有深入的认识,才能基于判断逻辑与触发条件足够的把控,将所负责的业务场景打通;(在这点上,若不是只做操作功能点的PM,可以用户产品功能架构,将个人所负责产品功能,从数据发布、管理、提取、仓促、分析,进行产品功能框架搭建)

总而言之

数据流与逻辑关系相互结合,能让PM在撰写产品需求文档时,让用户使用场景与计算机逻辑紧密结合,设计出符合用户体验的产品,结合业务场景进行功能取舍设计出符合平台战略或用户体验的产品功能点,提高了对应的转化率与实现业务(GMV)增长。


四、综述

撰写结构开发思维,是撰写产品需求文档非常核心的组成部分。是在模板或者样式的基础上,输出优质严谨的文档内容。在业务层面,与开发与业务方更严谨的进行良性沟通。而这些正是进阶版的核心所在,这个基础上,你可以根据实际的产品功能请看,进行PRD撰写与设计!

同时,将PM从发散思维的产物收窄至逻辑思维的产物,大大提高了PM入门门槛,提高了专业度。


五、附语

对于产品需求文档是否需要某类样式与格式?具体的样式与格式,可根据团队、项目实际流程与平台业务性质进行撰写结构进行设计,毕竟商业社会是以团队的形式进行作战。

但,作为个人,是否需要进行训练。倒爷001无法给你明确的答案,因为那是你自己的事。但是,从PRD角度,撰写完整的框架,能对你个人的产品框架思维得到训练。并且,文档是否高要求,其实也是你的事,至于开发看不看那是开发的事。出了问题,背锅的也是你的事。总不能让测试背吧?

大道至简,简难而繁易。处理一个功能点的框架思维与处理一个产品的框架思维是一样的。经过严谨的训练,能让框架思维得到提升,而框架好不好用,也决定了产品后续的迭代生长。

PS:需要倒爷轻自撰写的PRD文档节选,请添加微信:ftl_keen,添加时请备注“PRD”。终极版篇章,会直接进入PRD实践撰写。


六、抛个话题

如果上帝无法预测与控制宇宙的每个细节,在我们所能理解的所认知思维中,对我们存在认知进行设计,并存有大量以下的现象,如:50%的人类是畸形人、50%的天气是自然灾害、女性的占比率<=1%。那么,你认为Ta是一位合格的创造者?你会幸福?你的生活体验快乐?你还为这个维度的世界,延续你的基因?


七、延伸阅读

延伸阅读《刚入行的产品新人,倒爷教你写产品需求文档(基础篇)》http://www.woshipm.com/pmd/351529.html

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,088评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,715评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,361评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,099评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 60,987评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,063评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,486评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,175评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,440评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,518评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,305评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,190评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,550评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,880评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,152评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,451评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,637评论 2 335

推荐阅读更多精彩内容