首先解释一波啥是后台产品？所谓后台产品、前台产品我理解其实都是因为产品面向的最终客户群不同而区分开的：
后台产品面对的主要是客户和用户两类人群，客户是产品的需求产出方，他们有相对明确的需求和期望，比如企业的负责人或部门主管，而用户则是下面具体干活的人，他们一般业务需求较少，他们对未来的产品只有一个期望就是体验要好，减少学习成本；而前端产品面对的只有一类人群，就是产品的最终使用者，他们既是客户也是用户，需求五花八门，他们对价格，体验，视觉，业务都有不同程度的期望，可谓众口难调，所以更多的时候是前段产品经理来左右这些人群的需求。
其次前端产品重体验、重UIUE，要能让最终用户对产品一见钟情，时常推陈出新，所以产品可以牺牲质量，但要保证按迭代周期内有新的内容和功能可交付，这样才能最快速的试错，并同时降低试错成本；而后台产品是不允许出错的（有时候一个错误可能导致客户成千上万的损失），所以后台重质量而可以牺牲时间，而且后台不关注UIUE，试看SAP、ORACLE等大厂做的产品虽然难看，但有大把大把的客户，还贼贵。
最后总结的说：前端产品关注的是“人”，后台产品关注的是“业务”
言归正传，说了这么多那么一个后台产品或一个新功能是如何从0到1创造出来的呢？我的总结大概是分以下几步：
1、定位角色
2、统一业务词汇
3、挖掘需求
4、梳理核心流程
5、细化核心流程的叶子分支
6、拆分实体
7、拆分页面
8、定义数据字典
9、完成prd
其实这里每一块都可以大写特写一番，这里因篇幅有限就简单做一下介绍：
1、确定角色
做产品经理基本功就是需求分析能力，这是做好产品经理最最基础的要求（详见产品经理能力图谱），如果要想获取准确的需求，第一步就是找出产品未来都有哪些角色来使用，在这些角色中再找出究竟哪些是典型的客户（比如主管，业务），哪些是典型的用户(一线资深老员工)，只有找到合适的业务接口人才能获取最准确的一手需求，找对了事半功倍，找不对则事倍功半。
2、统一业务词汇
产品经理有时候就像一个翻译，需要将业务语言翻译成技术语言或反之，所以要想很好的和业务人员沟通首先就是要和你的调查对象保证认知同频，不能鸡同鸭讲，所有业务词汇得保持理解一致，比如sku代表什么？商品代表什么？只有业务词汇理解一致，才能开始后面的需求调研，否者很可能到最后推倒重来！！
建议会议参与者：100%业务人员
3、挖掘需求
结合之前的调查问卷，和统一的业务词汇以及对业务知识的基本常识，就可以开始对调查对象做需求调研了，调研时应注意以下几点：
3.1、不要被调研对象牵着鼻子走，不能对方说要什么就乱承诺，以听为主引导客户（用户）表达，也不要变成单方灌输（客户直接说要什么样的系统，或者产品经理告诉对方你会得到什么系统，避免先入为主），也不能搞成单纯的客户抱怨会，要适当的引导话题。
3.2、需要从不同维度获取需求，部门、业务线、操作流程、横纵交织，调研一次不行，那就多调研几次，不怕麻烦就怕遗漏和理解偏差。
3.3、需求调研后，要复述一遍自己的理解的内容，并确认你理解的是正确的，复述的方式可以采用用户故事的方式。
3.4、确定每个角色的使用人数和使用频率，后期可指导设计页面层级和技术接口设计。
3.5、收集的信息还不能成为最终需求，需要产品经理梳理信息产出需求，排优先级找出最有价值的需求，其他的可以放入需求池待开发。
建议会议参与者：100%业务人员
4、梳理核心流程
核心流程即是不能缺少的那些环节，比如支付、下单等，也就是01产品实现过程中不做就无法交付的需求，是价值最高的需求，保证一期的产品是可以被客户使用并能迅速产生价值的，这样后面从1到N的迭代就可以基于客户、用户的实际使用来针对性排期开发了，一切就run起来了。
建议会议参与者：80%业务人员 20%技术人员（主管参与）
5、细化分支
细化分支，是将核心流程上的功能节点进行细化，通过角色、需求调研的结果进行图形化展示，通常使用泳道图来表述业务逻辑，确保核心流程细化到每一个角色的各种操作与分支逻辑都展现到位。
建议会议参与者：80%业务人员 20%技术人员
---------------------------业务淡出，技术登场-----------------------
6、拆分实体
等核心流程和分支都和业务方确定后，就要开始展示产品经理技术一面的实力了，这时候需要产品经理针对细化的业务逻辑，将实体拆出来，虽然说需要一点技术背景，但也不用真正像技术人员一样去设计模型，只需要定义出实体之间的n对m的逻辑关系。
建议会议参与者：20%业务人员 80%技术人员（实际开发参与）
7、拆分页面
有了实体基本就可以确定页面和菜单了，这些页面如何挂菜单，需要根据用户的使用习惯和常用程度来设计，保证用户能快速找到自己常用的那些功能。
建议会议参与者：20%业务人员 80%技术人员（前段和测试参与）
8、定义数据字典
确认每个页面都需要哪些字典，写到你的prd上，同时整理成表格提供到技术人员。
9、完成PRD，并通过评审
最后一步就是输出PRD，因为之前的环节都是经历过层层审（怒）核（怼），枪林弹雨中已经能到这一步那你写的PRD一定是客户最终想要的，同时也是技术人员可以实现的，完成评审对你来说一定是水到渠成的事情了。
PRD的排版我的经验是将“页面说明”、“业务逻辑”，“数据字典”分开，这样做是充分考虑技术人员的阅读习惯，减少他们肉眼去扫需要信息的时间，而且不同角色的开发人员，对信息获取也是不同的，就这样一个小小的改进曾经让我在产品复盘会上收到过两个正字的好评，全是“prd写的很清楚，思路清晰”，同技术人员的关系也提升不少
说白了技术也是我们的用户，PRD就是产品，设计PRD时也应该考虑他们的体验。
建议会议参与者：100%技术人员
等PRD完成评审后，就需要产品经理展示其项目管理能力（保证交付，按时OR按质）、沟通能力（需求变更，需求理解有误）的时候了，那又是一场硬仗。
