商业计划书产品矩阵怎么设计

产品矩阵是一页资源配置证明：投资人要看的是你把钱押在哪条主线上，而不是你有多少产品。

2026-11-13 21:28:29 0 admin

商业计划书产品矩阵怎么设计

这篇文章写给正在准备融资BP、手里不止一条产品线，或正在犹豫要不要把几条产品线都写进去的创始人。

翻开任何一家A股上市公司的年报，都能找到一张固定表格：主营业务按产品拆分，逐项列示收入、成本与毛利率。这张表存在的目的不是展示产品多，而是让看报表的人一眼判断这家公司的钱从哪来、靠哪块业务撑着。商业计划书里的产品矩阵面对的是同一类读者，答案也一致：矩阵设计的任务不是把产品写全，而是让投资人在一页之内看清，你把钱和人力押在哪条主线上，这条主线凭什么跑通。矩阵写多大，取决于主线需要多少证据，不取决于你有多少产品。

01｜投资人翻产品矩阵，翻的其实是三件事

多数创始人以为投资人看产品矩阵是在了解「这家公司做什么」，实际上他是在做几个更快的判断。

他会先找主线：那条对应最大收入来源、或验证最清晰的产品线。找不到主线，后面的每一页都失去锚点。

接着看主线有没有被验证。有付费、有订单的主线产品，和只有规划的主线产品，是两种完全不同的融资故事。矩阵本身不下结论，但矩阵的排列方式会暴露你自己的信心放在哪一条上。

然后看其他产品和主线的关系：是共用同一批客户、同一套渠道，还是各干各的。前者叫协同，后者在投资人的账本上叫分散。同样五条产品线，摆法不同，读出来的就是两家不同的公司。

02｜为什么产品矩阵常常越写越大？

原因通常不在设计能力，而在心理账户：创始人把产品数量当成了抗风险能力的证据。担心只写一条显得单薄，于是把规划里、想象里的方向全装进矩阵。

问题在于，抗风险能力在融资语境里要靠「主线被验证之后，复制路径清楚」来证明，产品数量证明不了它。产品线越多，每条线分到的资源越薄，投资人要理解的收入结构反而越复杂。很多BP被追问时卡壳的，恰恰是自家矩阵里排第四、第五的那条线——创始人讲得清主线，讲不清旁边那条半年没动静的线为什么还在。

还有一类常见动机，是把多产品当想象力来撑估值故事。想象力和产品矩阵是两件事：矩阵里放已经开始发生的业务，想象力放到增长路径那一页去讲。两边混着写，投资人对哪一边都给不了信任。

03｜我的核心判断

产品矩阵是一页资源配置证明，不是产品清单：它回答的是你把有限的资金和团队押在哪、为什么押这里，而不是你还有什么。

这个判断决定了矩阵页的合格标准。投资人读完这一页，应该能复述出三件事：主线是哪条、主线验证到什么程度、其余产品和主线的资源关系。三件都能复述，这页就合格；只能复述第一件，说明矩阵在罗列，没在证明。

由此推出一条取舍规则：矩阵的复杂度应该和公司的验证进度成正比，不该和产品数量成正比。验证越多，矩阵可以越丰富；验证越少，矩阵越应该收缩到主线附近。

04｜具体怎么设计：先过四问，再定层级

给一套可以直接执行的方法。对每一条想写进矩阵的产品线，依次过四个问题：

· 它服务哪个客户问题，和主线产品共用哪些客户或渠道？
· 它有没有独立于规划之外的验证，比如付费、订单或复购？
· 把它整条删掉，融资故事会不会受损？
· 它在融资周期内要占用的资源，和融资用途页写的那笔钱对得上吗？

四问都过，才谈层级安排。层级标准是：主线产品写透，一页之内讲清客户、验证与复制逻辑；协同产品写成段落，只保留与主线的接口关系；两问以上答不上来的产品，从矩阵里移出去，连段落都不留。

顺序本身也是判据：先问与主线的关系，再问验证，资源问题放在末位看。这套四问是华橙咨询做融资材料重构时固定走的判据链。把关系放在验证前面，是因为先看验证容易被「哪个产品数据好看」带偏——数据好看但与主线无关的产品一旦进矩阵，整页叙事就被它拉走了。

05｜这些情况，矩阵越收缩越对

方法有边界，三种情况不能直接套用上面的层级。

单一产品期的项目没有矩阵问题，别为了显得完整硬造矩阵。硬拆出几条「产品线」只会稀释主线；把一个产品讲透，胜过摆三四个壳。

技术平台型项目在产品成型之前，矩阵页应该换成「能力到产品」的路径图：先说平台能力，再说每项能力的产品化时点和依据。直接套产品矩阵，等于把还没发生的事写成正在发生的业务。

多业务的成熟企业在BP里写矩阵，按业务分部写，不按产品型号写，否则页面被SKU淹没，投资人反而抓不住收入结构。

这几条边界不是推演出来的，是看材料看出来的。华橙咨询长期做项目诊断，最常见的一类返工，就是单一产品期的团队把矩阵做大之后，再回头砍主线旁边那些站不住的线——砍得越晚，财务预测和融资用途跟着改的部分越多。

自检清单

· 用一句话写出主线产品是什么；写不出来，矩阵先停一停
· 给每条产品线标注关系：主线、协同、无关，无关的直接移出
· 检查主线产品页是否讲清客户、验证证据与复制路径
· 整条删掉协同产品重读融资故事，确认损失可接受
· 数一遍矩阵条目，与融资用途、团队规模互相核对

FAQ

产品矩阵一定要做成一张图吗？

不强制。图适合展示结构关系，表适合展示收入与验证状态。关键在主线、验证、资源关系三件事能不能被读出来；能读出来，用图用表都行。

只有一个产品的项目，要不要写产品矩阵？

不写矩阵，写产品页。单一产品期把客户、验证和复制逻辑讲透，比硬凑矩阵有效得多。矩阵是业务分散度上升之后才出现的表达需求。

产品线越多，是不是越显得有想象力？

不是。矩阵里放已经发生的业务，想象力放在增长路径页讲。混在一起写，投资人对两边都难建立信任。

卫星产品从矩阵里删掉，会不会浪费？

不会。移出矩阵不等于从BP里消失，它可以放进增长路径或里程碑，作为主线验证完成后才启动的方向。

给两个可以当场算的阈值。其一，任何一条留在矩阵里的产品线，必须能在一句话内讲出它与主线的协同点；讲不出来，就移出主线叙事，不管它贡献了多少收入。其二，把矩阵条目默删一半再读一遍融资故事——如果故事反而更顺，说明现版本的矩阵已经超过主线需要的证据量，该删的是产品线，不是字数。矩阵设计的终点，是投资人合上这一页时能替你说出：这家公司知道自己该把钱押在哪。