“We are all in the gutter, but some of us are looking at the stars.
我们都在阴沟里，但有些人在仰望星空。”
——Oscar Wilde
奥斯卡·王尔德
这句话是如此有名，以至于超过了原作者本身。
注意了，我在标题上所说的，不是说要懂数据库知识。
那毕竟是个专业研发的领域，但对于产品经理而言，业务对象的信息结构是一定需要了解的。
在前几篇，我讲述了产品经理们该如何绘制四种流程图。
再加上这一篇的信息结构，以及后面要讲的状态位、策略。
组成了产品经理进行后端架构产品设计的四个组成部分。
让我们一点一点来讲吧，这都是很重要的产品设计的基础知识。
之前做民宿产品的时候，部门招过一个产品实习生，某天兴冲冲的做了一个产品方案递交上来。
要表扬的是小姑娘的主观能动性，不错。
但也有问题，就是我们团队在她做产品之前缺乏指导，造成她的脑力浪费……
她设计了一个看上去很好的产品方案，就是可以根据某些特色标签来去寻找民宿：
比如说推窗见山林的民宿；
比如说睡觉听海涛的民宿；
比如说可闻沙漠驼铃的民宿；
比如说大隐隐于市的民宿……
前端的线框图确实做的是非常的好，也能看出来她有一些美学观。
并且她对她的设计信心满满，希望可以立即上线。
这个时候我问她，根据你的分类标签来找民宿是没问题的，但你想过没有这些标签该如何获得呢？
也就是说，如何能够让全站的所有民宿，都可以展示出来这些标签呢？
她睁大了疑惑的大眼睛，说这些难道还需要我去想吗？
看，这就是产品经理初学者容易犯的错。
我说，我们其实是有不少民宿标签的，属于沉睡数据并没有使用。你的出发点很好，但你应该首先了解：
即便我们绕过这个问题的本源，即这些民宿标签真的可以加强用户付费的转化率吗？
仅从实现角度也能了解到：
……
最后的实现结果，就是她的产品方案变成了简单的运营专题，也就手工筛选了几百个民宿，上线了一个H5页面。
上线了之后反响寥寥。
因为用户真正的需求没有这么特殊，当然这是另外一回事。
只是说，如果她是创业公司的产品掌控者，这样一个她觉得简单的需求，恐怕也会让技术和运营人员忙活好一阵子，鸡飞狗跳了。
这就是我曾说的，为什么合格的产品经理应该对自己所负责的业务对象的信息结构，需要有很全面的掌握。
这也就是我在《只会做产品设计的产品经理不是好产品经理，更何况能做好的也不多》这篇文中所提到过的，产品架构要和技术架构对齐。
大家可以再回顾看看。
刨除互联网大厂，对于互联网创业公司而言，产品的信息结构基本上可以和技术的数据库设计相映射。
我拿一个通用的用户信息结构来举例吧：
注意和之前的文章一样，这也仅仅只是一个举例。
供大家理解就行，实际开发要根据不同的产品需求来实现。
从这个信息结构中，产品的信息结构设计和开发的数据库设计，进行了某种程度的上对齐：
对于有经验的产品经理来说，设计一个新产品之前，针对业务提前做信息设计，然后再和技术做沟通。
使用对方能理解的逻辑性语言来跟技术来进行对话，双方都会很舒服。
也能进一步的提升产品经理的领导力。
而不是产品的意见。
因为数据库设计是技术的专业领域，产品的信息结构设计是为了对齐，而不是去反过来指导技术的数据库设计。
这样产品经理就太傲慢了。
比如在数据库设计中，每个字段都有一个创建时间和修改时间。
这个产品经理可以不用考虑这么多，毕竟大多时候和业务无关。
比如用户之间的关注关系来说，因为这是个多对多关系，技术的基础方案是需要一个庞大的中间数据表。
那么产品经理就不需要考虑这么多，只需要考虑好策略方面的制定就可以了。
比如一段文本。
在技术中可能考虑使用整型、字符型、格式制字符、浮点型等等
产品经理只要规定是文本就可以了，技术去做具体实现。
话说我也不懂。
产品设计在迭代中，如果信息结构有了变化，一定要跟技术沟通对齐。
技术设计在迭代中，如果数据库中有了变化，并且和业务相关，也要和产品来沟通对齐。
考验产研相爱相杀的默契时刻，到了。
……
本文由 @觅云人 原创发布于人人都是产品经理。未经作者许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。