“产品经理需要懂技术吗？要懂到什么程度？”
这个问题翻译过来可以是：产品人对技术的理解程度会对产品的最终实现产生怎样的影响？这个影响有多大？
事实上，开发工程师在进行架构设计时，和产品设计产品方案时所面对的问题本质上是一致的。不同架构方案有不同的优势劣势，每个方案都有自己在成本效率上的考量。资源有限，在资源冲突时如何确定产品侧的优先级，最大化地贴合当时的产品策略，是需要产品和技术共同探讨决定的事情。
这些决策最终反馈到产品层面，就是产品的性能表现和产品的可拓展性。如果一个产品操作流畅性不够、反应迟缓、流量消耗大、稳定性不足，或是加多几个新需求就令开发头疼不已，所有这些表象都有可能来自一个与需求不够贴合的架构设计方案。
所以我们需要关心的问题关键其实是：产品能在多大程度上让架构设计贴合产品需求？这里面包含了两个关键点：产品与技术的协同力、技术开发的实力。
产品越懂技术或技术越懂产品，协同力都能最大化。但作为产品的第一责任人，我们不能总期待着技术来理解产品，而需要磨炼将需求翻译成技术语言的能力。
以微信朋友圈的架构设计为例。
丁香园CEO冯大辉曾发布过一条微信产品经理面试题，题目是：朋友圈的基本数据结构设计是怎样的？为何它既能做到完美阅读权限设置，又能兼顾性能？
这个问题的定义很清晰，我们可以直接按四步法则把问题拆解为五个问题：
Q1：哪些是与性能无关的数据问题？先排除。
Q2：微信如何处理关系链中的权限？
Q3：从用户刷新朋友圈到所有信息流数据显示到用户手机客户端上，这一过程存在哪些不同的设计方案？
Q4：分析这些方案的优劣点，以及它们对产品性能有什么影响。
Q5：微信如何做出取舍，确定最终实现方案？
先来看Q1，比较简单。像文字、图片、时间、位置等数据类型是单独存储的，它们和权限、性能无关。不管是哪种类型，适用的规则都是相同的。
再看Q2，微信采用了“标签分组”的方式进行关系链的权限管理。在产品形态上，从表面看是双向关系，底层的数据存储却是单向的，即每个用户各自存储一套自己的通讯录数据。所以，当有人把你从他的通讯录中删除时，你是不知道的，因为你自己的通讯录数据没被修改，这个人还会保留在你的通讯录中。
Q3，从用户刷新朋友圈到信息流数据显示出来，这一过程的主要设计方案（细节不论）有：
同步内容剔除法，最简单粗暴的A设计方案：
A设计方案图：同步内容剔除
用户刷新朋友圈时，先读取用户所有朋友的消息数据，然后进行筛选过滤，把不应该展示的数据给依次剔除掉。比如没有查看权限的消息、已经屏蔽了的用户消息。
采用异步内容分配法的B设计方案，将大计算量在时间上进行重新分配：
B设计方案图：异步内容分配
当用户发送消息到服务器时，服务器立即依据好友关系中的“分组标签”，将消息分配给存在标签的用户。不过这时分配的消息是存在每个用户的Timeline中的。这个Timeline我们可以理解为每个用户单独拥有的一个准备数据池。然后接收方用户在刷新朋友圈时，直接拉取自己那份Timeline中的数据，客户端做一次屏蔽过滤操作，把用户屏蔽掉的消息剔除就可以展示出来了。
B方案的差异版C方案：
与B不同的处理方式是：把屏蔽人消息过滤放在最初消息发布时来做，而不是接收端最后来过滤。
Q4：下面来比较一下A、B、C三种方案在性能方面存在的差异。
我们知道，微信拥有海量用户，每个用户在任一时刻都可能执行“刷新朋友圈”的动作，这一个小小的动作有着极高的并发量。
按照方案A，用户每次刷新朋友圈，客户端都要跑到消息池里去找通讯录朋友们的消息，还要对找到的每条消息执行逻辑判断。这种执行效率显然是不能被接受的。
而按照方案C，在消息发布时如果就考虑屏蔽的人，那就意味着要去读取每个有权限阅读的人的屏蔽人清单，再根据每个人的清单决定是不是放到这个人的Timeline中，这种操作显然会增加计算量，降低方案效率。事实上，我们可以通过一个方法来验证C方案不是微信的选择：当用户把一位好友屏蔽时，不会看到对方的任何消息，但如果用户在此时取消屏蔽，则立即能够在朋友圈中看到这位好友发布的所有消息（包括在屏蔽时间内消息）。
不过B方案也并非十全十美。运用B方案意味着朋友圈的消息不能编辑，只能删除。因为权限控制是在发布消息时就确定的，如果增加编辑功能，一旦用户在编辑时调整了阅读权限，就需要将之前写入用户Timeline中的数据给删掉重写一遍，成本比较高。不过这一点缺陷在产品侧看来不仅可以接受，还进一步约束和简化了朋友圈的操作。这就是产品需求与技术实现达成的一种共赢。
所以Q5的答案来了，我们会认为方案B才是微信最终选择的架构方案。
类似的架构设计思路还体现在微信红包和企业微信通讯录同步的设计方案中。这些架构方案要面对的共同难点是：高并发量、高安全要求。
对微信红包来说，按照2017年1月28日微信公布的数据，除夕收发红包量高达142亿个，而收发峰值也达到了每秒76万。并且，用户发100元的红包绝不能被拆出101元；用户发100元只被领取99元时，剩下的1元在24小时过期后要精确地退还给发红包用户，不能多也不能少。而对于企业微信，大型企业员工数超10万，企业的通讯录架构信息隐私性强且细节多变。所有这些需求场景，都对系统的架构设计提出了巨大挑战。
如何通过精妙的架构设计来应对挑战，确保系统高效率、零故障运行？其主导思路就是我们在“拆解问题”的方法中提到的任务切割。从时间维度上进行任务切割，把同步变异步，从流量维度上进行任务切割，把洪流变细流。
PRD：需求的转译
关于如何写PRD（Product Requirement Document，产品需求文档）这件事，我认为自己没什么发言权。
因为在腾讯工作期间，我的PRD就写得不怎么样。靠着产品Sense很强的开发工程师们的包容和支持（感谢QQ同步助手团队的伙伴们）——PRD写得不够细致严谨的地方他们会提醒我，我再补上；就这么磕磕绊绊，才能每次在需求评审时勉强过关。
后来离开腾讯去小型的初创公司，就更没有完整输出过PRD了。而是将主要时间花在了和团队其他成员的沟通讨论以及框架和原型的设计上。那些需要用严谨语言描述的细节，在小团队项目开发中是一种奢侈，时间成本不划算。更多还是依靠成员间的互信配合，以及项目工作流平台的信息备案，快速讨论快速做，遇到问题随时沟通。
以上完全没有否认PRD价值的意思，事实上，有些互联网公司在面试的时候为了节约筛选成本，会要求应聘者发一份自己写的PRD来看。能把PRD写得严谨漂亮，是产品人专业素养的一种体现。只不过就像相对思维里讲的那样，没有人是完美的，有光即有影，各有优势劣势。我自知尚存，明白自己在这方面确实做得不好。
如果容许一个PRD学渣来聊聊自己的看法，我会认为PRD本质上是一种对需求的转译，将需求准确翻译给开发工程师、设计师以及运营和测试团队，尽可能早地消灭团队对需求的任何误解。
在流程规范的大型互联网公司里，团队比较大，成员众多，甚至很多产品有多个产品经理在跟进不同模块，这时候维护一个规范的PRD确是团队节省沟通成本的重要方式。
最后，学渣的模板是不能信任的，所以，在网络上搜一搜，应该有很多更棒的。