内部使用的系统不仅经常得不到应有的重视，而且内部业务方提需求时往往觉得理所当然，很容易形成“烂摊子”，对于产品经理来讲真的很难。所以关于内容使用系统的产品调研就显得无比重要。
内部使用系统相对C端产品有哪些鲜明特点：
劣势：
公司重视程度低
迭代相对更慢
需求主要源于业务方案迭代，很多时候产品同学话语权低
优势：使用对象“个体角色化”，同部门个体差异小，调研可执行性更高
A：新产品规划、新功能设计、系统一段时间不更新积攒了一些抱怨和需求等，总之调研时为了使整个团队在产品的需求现状和未来规划能更好地达成一致，甚至以此拒绝一些业务方不合理的需求等，通过调研及总结汇报，能够提升产品负责人对产品的认识和影响力。
Q2：调研目标？
A：数据方面：清晰呈现系统当前使用指标走势并分析合理解释；
用户使用方面：分组用户在系统上的核心业务、动作、近期需求，以及其他优化建议；
Q3：调研步骤？
A：本次系统调研主要分为三个环节，每个环节4至5个步骤：
1. 系统定位
系统定位是相对比较宽泛的内容，这里需要提炼出系统在初始规划的定位，包含系统slogan、目标人群、功能方向或功能主题(最好都能贴对应的图片)等内容。
汇报材料的呈现方式举例：
注：“少即是多”适合来描述系统定位，底部加相应图片增强感知。
2. 产品功能架构介绍
有了概况之后，有必要对产品做个比较详细的功能架构介绍（如果是以呈现内容为主，围绕信息架构展开）。为了信息更饱满，最好也要加上每个模块的使用指标现状。
汇报材料的呈现方式举例：
注：顺序和颜色分别突出模块/页面之间的关联性、重要程度。
3. 系统迭代轨迹
系统迭代轨迹很重要，让人清晰地看到前面的伙伴付出的努力和系统不断健壮的过程。
如果当前开发的密集程度明显低于正常水平，而且近期开发的功能比较辅助，都能够直观反映出当前的开发困境。
这个步骤的材料呈现方式就用表格好了，表头包含版本号、上线时间、版本内容三个部分，网页端和移动端最好分开阐述避免信息重叠。
4. 使用现状数据指标
这个步骤大家司空见惯了，主要是反映诸如“这个系统到底有多少人在用？”、“这个系统主要是哪些人在用”、“用户的使用频次怎么样？”等信息。前期大家对用户的操作行为、埋点规则，以及埋点采集质量不确定的情况下，建议相比PV指标和使用深度指标，UV指标更合适一些。
另外，很有必要认真考虑数据维度的切分，比如分日期跨度、分使用端、分部门、分模块/页面等。
汇报材料的呈现方式举例：
5. 调研对象筛选
埋点数据是最有说服力和全面的数据源，使用对象少的话直接全部发，多的话可以考虑分部门、分模块、分使用频次来筛选调研对象。（如果没有埋点数据，建议从组织架构挨个部门询问…）
题外话1：产品经理数据分析能力在这个地方发挥作用了。从埋点取数、数据清洗、频次分维度统计、生成收件人列表等需要sql、python/R语言的简单代码支持。
6. 问卷设计
首先要秉持：“调研是为了验证”，验证你的假设。在这个基础上，再从问题上做些讲究，比如转变提问的方式、相似的问题叉开问等来保证验证的效果。问卷的载体使用问卷星开放的免费功能就够用了。
针对核心假设，调研问题设计举例：
假设：“绝大部分用户现在使用某模块只是为了从页面上导出数据”
Q1：“您平时在这个模块最主要使用什么功能？（单选）”
Q2：“您最近三个月在这个模块除了Q1所选的功能，还使用哪些功能？（多选）”
…
Q15：”这个模块您有没有之前用但是最近三个月已经不用的功能？（如有请帮忙详细描述）”
7. 问卷小批量试验
脑补一下”上千封的问卷填写邀请已经发出，之后发现有很多问题需求调整优化…”
毋庸置疑，用户耐心有限，这一步骤不可或缺。排查一下有没有“调研内容不全”、“问题意图不明”、“选项文字不清楚”等情况。这个步骤最好请几位跨部门的深度用户来试填，对了，别忘了请示领导是否有不足…
8. 问卷优化（注意要点同 问卷设计）
9. 调研执行
这个步骤只有一些小建议：
每个部门找到一位联络人，找联络人帮忙在部门发个通知；
上班之初、快下班(特别是周五)是用户比较愿意去填问卷的时间点；
邮件语气“任务式”比“邀请式”更有效（用户也不清楚调研背景），不过凡事把握尺度。
10. 问卷总结
这个步骤是总结汇报的重点，所展现的信息篇幅也足够自成一章。针对内部系统用户角色化的特点，相对于按“问题”线来展开描述，按“部门角色”线展开能更好得刻画角色特点。数据展示最好按分部门来展开。内容依次要包括“调研背景简介”、“问卷收回情况简介”、“调研结果呈现”、“需求点总结”、“调研不足总结”。
问卷收回情况简介举例：
注：这部分信息主要是呈现收回的调研数据全面，能够反映问题现状即可。
调研结果呈现举例：
注：问题结果可以有各样的展示，重点把握关联问题聚合、避免信息重复出现、重点突出等。
需求点总结举例：
注：通过块大小、颜色来反映用户对需求点的急切程度。
11. 团队内部开发心声收集&其他产品经理心声收集
这两个步骤内容比较单一合并在一起。本质目的是使调研反映的信息更加饱满，体现考虑问题的全面性，同时也为后面的结论做一个铺垫，告诉大家某某方面不是产品经理一个人的意见。
呈现方式简单对称、对齐陈列即可，文字考虑写在“消息框”里给人更强的场景感。
12. 关联产品对比分析
首先，就算是内部系统，也很有可能有其他产品提供了相关的功能。系统迭代越慢，业务方就越有可能找其他部门实现需求；
其次，其他系统也会有相应的产品规划，如果其在一部分功能上定位更明确，也可以作为我们砍掉一部分功能进行重构的理由；
另外，这个步骤应该在用户调研之前就应该有所准备，这样对应的调研假设才更具价值；
关联产品对比分析呈现举例：
13. 总结远期规划和近期开发
这个步骤是整个调研和汇报的结论页，产品经理先根据自己的判断写下提议，和团队领导和同事汇报讨论后可以修改作为会议纪要页。
内容呈现主要围绕远期规划（前）、近期开发（后）展开，举例如下：
三、调研汇报注意要点
汇报避免介绍太多容易丢失重点、先入为主等，数据页让数据说话；
目标是团队领导和同事对产品现状和未来规划达成一致，所有准备都要紧盯这个目标。
