最近恰好读过两本与营销和产品相关的书：《解决：营销就是解决竞争》《做对产品》。
前者从营销视角讲授，企业应当如何定位 才能以弱胜强
后者从产品视角讲授，如何将一个创意 推向市场
这两本书综合起来，可以帮我们形成更加系统化的思维框架。
我始终认为，工作和生活不应当充满低头和无奈，而是应当一次又一次的思维升级，兼容并包。
ToD 业务的特点
当前我们正在做的业务类型是 ToD（面向开发者提供服务），它虽然跟 ToB/ToC 有很大的不同，但仍然有很多可以借鉴的地方。
关键的不同：服务的提供方跟用户平权（因为用户是开发者，也会编程）
相似之处：不论做什么类型的业务，都是通过产品力来吸引用户，赢得市场竞争
很多 ToD 团队是没有产品经理的，这可能是因为大家都是开发者，自认为是理解用户的，但其实不然。
缺少产品经理（或产品体系、产品思维），导致的一个头号问题是：我们开发出来的软件，卖不出去。
由于又缺乏产品相关的思维体系，大家很容易将 “卖不出去” 归结为 “没有卖好”。
但其实除了 “没有卖好” 之外，还有另外一个（可能是更重要的）原因是 “没有人需要它”（或 “没有市场”）。 因此，本文想阐述一下这个观点，在没有完整的产品体系之前，我们应该以产品优先，其次再考虑技术运营。
企业中每个部门所做的事情，都只是公司整体商业形态中的一环。 比起做好一个产品，提高产品的品质 等 “细枝末节” 的事情而言，从整体上系统的分析问题，无疑是更重要的。
产品体系
那么我们应当如何搭建产品体系呢？可以想一想 “有产品经理” 团队的研发流程是怎样的。
先以最低的成本验证市场，再投入更多的资源进行研发
数据胜过意见，用数字说话
有完整的、科学的 产品研发流程：市场调研、原型设计、需求评审 等
针对这些失败的产品所做的所谓的市场调研，大多数都不是在真正的市场中进行的，而是在我称之为 “空想之地” 的一种虚构环境中进行的。 如果一个创意在空想之地逗留时间太长，就会陷入由未经证实的恣意判断、信念、偏好 和 预测 组成的谜团之中。
缺少产品体系的团队，“专家意见” 就会冒出来，但又由于产品成败与这些专家的切身利益无关，其实这些意见的参考意义并不大，专家往往不会比普通人知道得更多。
此外，对什么样的 数据/指标 才能用于衡量产品成败 难以达成共识，甚至压根没有这样的指标。
这就会导致很多 “想法”（或项目），无法证明是失败的，最后都会落到 “推进难” 的死循环中。
那么如何才能确定 我们在做市场需要的 产品呢？
创意有很多，我们需要的是筛选力，而不是执行力
我们要离用户更近，离竞争对手更近
在产品迭代前期，对技术可行性/方案的分析要减少争论，对于到底有没有人来用要加强验证
搭建产品体系的目标是，赋予团队中每个研发独立开发技术产品的能力。
再谈技术运营
那是否 我们只需要搭建产品体系就够了呢？并不是，我反而认为，技术运营也应当视为产品体系中重要的一环。
只是它必须依托于产品体系之上，不能独立存在。
即使是软件架构相关的资料中，也有类似的观点，《软件架构师应该知道的 97 件事》
有这样一种观点，认为设计优良的框架，细致考虑并精巧实现的架构自然会被人们重复利用。
事实上，即便是最精美，最优雅的框架，可复用性最高的系统，也必须满足下面的条件才可能被复用。
- 大家知道它们存在
- 大家知道如何使用它们
- 大家认识到利用已有资源好过自己动手
如果大家找不到可复用的资源，或者不知道如何使用这些资源，人的天性就会发挥作用。他们会自己动手实现，到头来吃亏的还是架构师。
宣贯在产品推向市场的过程中，起着无比关键的作用（前提是这个产品确实有市场）。
当人们都不知道这个产品存在的时候，即使这个产品再好，也没有人来用。
所以在整个产品体系中，在扩大市场的阶段中，我们需要更好的进行宣贯。
结语
搭建产品体系，优于 单点考虑的 加大技术运营力度
ToD 业务仍然需要通过产品力来吸引用户，赢得市场竞争，所以懂得如何做好一款产品很重要
技术运营在市场扩大阶段，仍然非常重要，但前提是做出来的产品要有市场