#个人观点#

后台产品经理的日常：

后台系统的产品经理每天面对的其实不是C端用户，所以通常也不会去关心自己系统的UV、PV，他们更多的是不断周旋于企业内部的各个系统使用方（B端用户、前端产品经理、运营等）和业务方（运营、运维等），在满足当前的业务流程的前提下，绞尽脑汁的去想着怎么优化流程，怎么提高业务方效率。

所以后台的产品经理的工作职责：

1，明确整体后台系统的业务流和数据流，能够梳理出后台逻辑规则。

2，明确业务规则，将业务规则转化为明确的需求项。

3，明确中后台每一项需求分支的信息字段分类及归纳。

4，将整体后端产品共通的工作项串接、关联。

一个后端产品也不一定就完全不懂前端，作为履历和经验多一些的产品经理，应该会站在整个业务线的角度去看这个问题，可能会考虑业务线怎么挣钱，业务线产品的milestone是怎么样的？如何实现每一个阶段性的目标。从商业模型的角度看待整个产品，不至于只是看到业务提出的需求或自己构想的一些细节实现方案。

总的来说：产品经理都是练出来的，不是想出来的。多动多动，动起来！！！

这种问题，啊就...如何评价一部戏的好坏？这三言两语肯定是说不完啊，当然是不同场景不同标准。

如果是要考察你的后台设计思维，你可以说需要满足可视化、数据源、控制性、内部设置四项原则，整体系统或者单一模块最好都可以遵循或者对号入座。

大的业务又不止一个后台，这些后台如何协作支撑前台才是真正的好坏标准。而且很多B端的产品，本身既是前台也是后台，这都得在提问时讲清楚，要不问得也太业余了。

总的来说，后台产品相比前台是更容易做到一个还不错的标准的，毕竟他的最大需求也就是功能性，便捷性甚至安全性都算次要需求，所以适合新手产品经理做。

在阅读《启示录》的时候，书中谈到一个观点，如何为产品制定一个评价好坏的指标。书中给出了一个解决方案，就是收集用户是否愿意将产品分享给其他人。

因为如果一个用户认可你的产品，那么他就会因为自身的满意而对这款产品产生自信并共享其他人。

这个指标相较于业务明确的KPI是一个非常好的补充。

回到这个问题中来，我自己本身目前就是一个SAAS产品设计人员，如何评价我的产品质量，也是我在思考的问题。

如果你直接问使用者好用不好用，其实根本得不到答案，但凡后台有一个他们觉得不顺的地方，都会让你感觉这个产品不太好。

后来根据《启示录》给与的启示，我对我所负责的产品评价依据定为以下几点：

1. 作为使用者，您是否愿意将这款产品分享给更多人呢？

2. 作为一款旨在解决XX问题的产品，AAA（即本产品）是否有效的解决了你的核心问题呢？

这两个问题在我拜访或是为其他公司使用者做说明的时候都会问到，他们会给我直接的反馈，我便能了解到他们的满意程度，以及对于这个后台使用的好坏感受。

基于此，未来等待用户扩大到一定规模的时候，我打算把以上两个问题再细化一些，设计为数值打分制。

以上是我的一些思考，抛砖引玉供大家一起讨论。

• 1.角色分组
• 2.权限控制，业务拆分
• 3.可动态配置前端核心功能和关键数值
• 4.模块化，扩展性强
• 5.数据源唯一性
• 6.可视化报表导出

补充一下思路： 

1、可以先阐述下产品好坏的评估方式，比如从需求价值目标出发，有没有切实解决用户的痛点------这一步展示你对产品的理解

2、再补充下后台这个垂直方向的产品的侧重，比如易用性，可拓展性等等------这一步展示你对后台产品的认知 

3、最后再回到自身，你怎么评估自己做的产品，可以从实际出发吧，比如用户、业务方、老板、leader、团队内成员等不同角色的评价来论证，如果有具体的增长指标就更好了------这一步展示你的业务能力  

如果是我面试回答的话，我应该会沿着这个思路来展开

• 系统角色和权限是否划分清晰，提交申请，审核等流程是否通畅，每个人能看到并处理自己负责的业务模块；
• 业务人员使用流程是否闭环，各种异常情况系统是否都能处理，如果某一个人员未处理是否会影响整个流程
• 系统菜单是否划分清楚，是否能让用户一下子找到自己要找的
• 能否辅助业务人员决策，而不是每个地方只起记录的作用
• 能够支撑前台需要灵活配置的模块

很关键的一个点是：“是否可以支持灵活配置支撑各业务线的需求”。

后台产品分很多种，但都是为了提升效率、控制成本和业务增长，从这三个角度拆解阐述，可能会好点

blued?

当然是需要问使用的人的意见，是否满足他们的需求

可用性——能支撑业务能力，解决多数功能

易用性——逻辑布局清晰，学习成本低，操作简洁

灵活性——可拓展至多业务场景，灵活支持

不同层面的判断标准不一样，不过从终极角度来说，产品是人工制品，它最终的成功就是实现了产品设计者的意图吧，无论上商业上的，还是技术和社会上的。