架构，是一个偏向宏观的事情。
设计，是一个偏向细节的事情。
技术架构，是将产品需求转变为技术实现的过程。
产品架构，应该是将需求转变为产品需求的过程。
产品架构，最考验PM的判断力和设计能力。
以大家都熟悉的知乎为例，来设计一个问答网站。
首先会有用户、问题、回答这几个对象。
用户对回答可以，赞同或反对。
用户可以通过评论回答，或私信的方式与答主交流。
用户可以关注答主。
...
所以我们可以先整理出基本的信息对象和动作。
用户、问题、回答、赞同、反对、评论、私信、关注。
随后，我们要提供问题和回答的曝光方式，
我们可以在首页做一个中心化列表，来把问题曝光出来，获取流量。
运行了一段时间后，我们发现一个中心化列表很难满足所有用户，于是我们推出话题对问题进行分类，提供信息流的效率。
又运行了一段时间，我们发现话题也解决不了中心化带来的问题，大部分都集中在少数问题上，于是我们退出了动态来形成每个人的 Feed，让问题有了更好的曝光，随后我们又增加了无所不能的关注，来丰富 Feed，对人、问题、话题、收藏夹...
为了收集回答，我们推出了收藏，而为了整理收藏，我们提供了将问题列入一个个清单。
......
这个过程中，我们不断遇到问题，然后判断它是不是要被解决，再选出解决问题的方法。
我想这就是产品架构中最重要的部分。
判断需求的真伪和优先级，需要PM对业务有足够的了解。
选出优秀的问题解决方案，则需要PM有足够的工具方法积累。
知乎，是一个功能比较丰富的产品，学透了知乎，就完了积累的一大半。
当然，一切都不是万能的。之前李奇老师提出过，并不是所有的需求都可以利用现有的组件堆一堆来解决问题。
一个典型的例子就是，微信如何解决公众号抄袭问题。
普通的做法就是加个举报功能了事。
微信后来则推出了“原创”功能，利用机器来自动识别是否抄袭。
这就是一个超越现有方案来解决问题的方式。
当然这部分更偏向细节，与架构并不那么相关。
完。
