做产品，不要忘了产品的“度”

产品设计要有“度”，这个“度”分为产品策划与产品设计两个层面，每个层面上都有很多产品经理需要考虑的问题，

首先说说什么是产品的度，套用管理学的一句话：

产品设计是一门科学也是一门艺术，所以产品的度此处论产品的科学性和艺术性，一个好的产品两者兼具，但又都不会过，一切是最合适的。

说说产品的科学性和艺术性，用脑图做个梳理：

其次用xmind分析下产品的度受产品经理的性格、专业能力、行业经验的影响：

有哪些具体可执行的方法可以让我们在实际工作中参考呢？

以下是从一些经验的总结，希望能给大家带来些启发； 从两个层面来阐述：产品规划层，产品设计层。

一、产品规划层

产品规划决定了产品的方向，就像一栋建筑，规划图决定了建筑的风格特征和结构特征，建楼人员只能在不违反设计师的规划上进行建造，好或不好（质量除外）就是设计师的问题。

很多人可能觉得产品规划都是很宏观很大的事情，小的功能没必要规划。其实不然，规划是自上而下的，小功能仍然需要规划。

只不过小功能规划必须基于整体系统规划的方针，小功能也要规划功能的内部结构，前端和后台架构，增删改查功能，操作层面和运营层面需求，基础版和智能版等等。先规划好，才能有步骤地做，即使出现突发的外部变更需要紧急更新迭代，也不会出现无从下手的感觉。

产品规划层面一般有以下几点注意：

1. 清楚地了解公司当前发展阶段

公司像产品一样，也会经历几个阶段：初创期、快速发展期、成熟稳定期、下滑期。

每个阶段公司的主要任务不一样，那么对于产品给公司带来价值的期望也不一样，我们做产品规划一定要结合当前发展阶段来考虑，不要照搬行业类似产品的规划，也不要想着一开始就做多长远的规划。

1）初创期

初创期的公司就是生存，产品能支持业务为优先，规划围绕收入、客户、业务量来考虑。

2）快速发展期

快速发展期的公司产品规划要逐步考虑系统稳定、流程标准化、降本增效，很多公司在这个时候可能会发现流程、系统要重构，那就重构。

3）成熟期

公司进入成熟稳定期之后，更多考虑优化，一方面要从细节处入手，一方面要从自动化、智能化、新技术入手。

4）下滑期

公司如果在下滑期，那可能有两种走向，一种是一去不复返，一种是力挽狂澜，这个看企业负责人。

一去不复返型的也没什么好规划的了，力挽狂澜型的就要看公司着力的点在哪，横向扩张业务or转型，还是深耕细作。

横向扩张业务自然是要考虑多元化，产品规划就要多去市场看看人家的是怎样做的（失败的、成功的都得看），再回过头来看看适合本公司情况的可能有哪些，最后是一定要跟高层沟通，沟通，再沟通。

转型的那就得看公司的方向了，相当于重回初创期。

深耕细作的，我们自己也要从公司的层面出发，看看产品在哪些方面可以做得更细，一般着重于延伸客户服务，比如围绕客户可以开展增值服务or关联度比较高的业务。

2. 了解清楚各部门KPI

了解清楚各部门KPI就是了解清楚各方的利益所在，产品如何能够帮助各部门提升自己的KPI，或者如何防止上了系统损害了各部门KPI。

了解清楚这个才能在实施时得到支持，了解清楚之后，在做产品规划的时候就要相应规划一些管理类的报表、预警、监控相关的功能。

3. 经验只是用来借鉴的，不是照搬的

我们历史公司的经验一定不能照搬，一定要充分考虑清楚当时那么做的背景和原因，再结合当前公司的实际情况，如何选择和放弃一些，如何改造一些，否则就会发生灾难。

4. 产品结构图要画

对于一整套新的系统来说，一定要有个整体的产品结构图，这就像是大楼的设计图，有了这个就好继续进行下一步的拆解，并且不会脱离主线，大家也可以各领任务了。产品结构图可以根据该业务涉及的公司组织架构和职能来梳理和搭建。

5. 系统功能清单要列出来

我们要有在设计前列功能清单的习惯，这就是个更细的活了，包括功能、接口，列得越细，后面出现遗漏的可能性就越小。

二、产品设计层面

产品设计层面，很多时候是考验产品经理对人性的理解，也就是常说的换位思考能力。其实这个能力也是来源于一些经验积累和方法的使用的，以下针对关键的一些点做说明。

1. 耐心梳理业务场景

很多人不喜欢梳理业务场景，或者说脑海闪过自己知道的那几个就算了，也没有细细去区分不同场景的本质区别。所谓“磨刀不误砍柴工”，业务场景梳理就像一个病人的症状先了解全面才能看好病一样，不做好这关，最后出来的系统往往会被人诟病产品经理不了解业务。

所以这件事马虎不得，梳理这事没有捷径，通过问人，亲自去现场等方法去了解，然后用XMIND/EXCEL等工具进行梳理就可以。

2. 对你的用户有个清晰的认识

什么叫对用户有个清晰的认识呢？

性别，年龄，身体状况，文化水平，工作环境，工种特征，这些都要了解清楚，有个整体全面的认知。因为你了解了这些，才知道你的用户更细节和隐藏的需求。

这些需求可能是功能便捷性和用户体验方面的，是需要产品经理的换位思考和场景代入来进行思考设计的，实在无法想象的，就到现场亲自实操。

产品的业务逻辑，产品架构这些是核心，而产品的功能便捷性和用户体验就是体现产品经理用没用心的地方了，往往是最容易被认可也最容易被人骂的地方。用户不懂太深的东西，首先就是要用得爽，无论C端还是B端产品，在这点上是一致的。

3. 别给用户挖坑，也别太过于自信

给用户挖坑的是什么样的功能呢？

举个例子：

一个功能本来是用于某个特定场景的，产品经理为了所谓的保留“扩展性”就没有做约束，结果另外的场景你发现用这个功能也可以操作。问题是，到下一个操作的时候你发现操作不了了，为啥？因为下个功能又没有兼容上一个所谓“扩展性”好的功能。

这种就是产品经理挖的坑，这种情况，首先是做好取舍，其次是是否有全局观；具体一点就是不要把鸡肋功能和“扩展性”等同，扩展性不代表留一个模棱两可的功能；另外就是一旦决定这么干了就得做好全流程的重新梳理。

别太过自信是指什么呢？

就是管得过多，做得过多，什么都想系统来约束死，不给用户选择的权力。有些场景确实是无法抽象出规律的，硬要取一两个规律当普适规律，别的就不给玩了。

原因是什么？

害怕用户犯错，其实仔细想想，用户在这个环节上的利害关系本来就高，管理手段也到位了，业务场景上就是需要有一定灵活性的，就完全可以把选择权交给用户。

4. 批量操作一定是不可取的吗？

对于一线用户来说，系统某种程度上来说是累赘，不操作系统最好，所以就诞生了很多批量操作的需求。

这个时候产品经理就得深入分析这个批量到底会有什么坏处，如果不批量是不是这些坏处就一定不会有？有这些坏处跟效率比起来哪个更可以牺牲？有些时候批量不一定不可取，这里综合考虑的就是后果是不是可以承受的，还有问题发生的概率。

5. 一味地坚持己见不一定能树立威信

产品经理都很注重自己在研发、测试童鞋面前的威信，这是没错的，但是千万别让自己为了威信一味地坚持己见，完全听不进别人的意见。

很多时候在具体的实现方法上，可能研发、测试给的建议是更好的，所谓产品评审，不要想着自己就是被审核的人，别人提出建议不代表自己被否认。

设计这事本身就没有绝对的对错，不偏离原始需求的情况下，只要有道理的就可以采纳，慢慢地自己的技术水平也会得到提升；也能提升研发测试人员的参与感，这有点管理的范畴，但确实很重要。

重要的是，我们要认识到做产品工作同时也是一项自我的修行和认知的提升过程，用工匠的心态来对待自己的这份职业，坚持、不断改善，就能更加专业。

本文由 @lena 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: